BBS Toolkit

home *** CD-ROM | disk | FTP | other *** search

/ BBS Toolkit / BBS Toolkit.iso / rbbs_pc / rbbsdoc.zip / RBBSDOC1.DOC < prev next >

Wrap

Text File | 1988-10-01 | 342KB | 6,043 lines

REMOTE BULLETIN BOARD SYSTEM for the IBM Personal Computer Version CPC17.1A Technical Reference Guide Technical Support Number (203) 268-9656 (calls returned COLLECT) Copyright 1983-1988 by D. Thomas Mack 39 Cranbury Drive Trumbull, Conneticut 06611 DATA #1 -- (203) 268-5315 #2 -- (203) 268-0129 Jon Martin 4396 N. Prairie Willow Ct. Concord, California 94521 DATA -- (415) 689-2090 Ken Goosens 5020 Portsmouth Road Fairfax, Virginia 22032 DATA #1,2,3 -- (703) 978-6360 October 2, 1988 RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 2 of 232 TABLE OF CONTENTS Page ----------------- ---- 1. INTRODUCTION 6 1.1 The Capital PC User Group 1.2 The "contributions" requested for RBBS-PC 1.3 The "history" behind RBBS-PC 7 1.4 RBBS-PC Update Conventions 14 1.5 Beta Test Sites, Where and Why 15 1.6 An Example of "Users Helping Users" 17 2. Summary of RBBS-PC's Features 19 2.1 General 20 2.2 Messaging 2.3 File System Management and Exchange 22 2.4 The User Interface 24 2.5 SYSOP Protection 26 2.6 SYSOP Functions, Features, and Support 27 2.7 System Access Management 28 2.8 Communications Support 29 2.9 "Base-Line" Hardware and Software Requirements 30 3. RBBS-PC's SUPPORT POLICIES 32 3.1 RBBS-PC's Vendor Support Policy 3.2 RBBS-PC's User Support Policy 36 4. HOW TO GET A COPY OF RBBS-PC SENT TO YOU 36 5. FILES RBBS-PC USES 37 5.1 RBBS-PC System Files 38 5.2 RBBS-PC Text Files 41 6. INSTALLING RBBS-PC FOR THE FIRST TIME 44 7. THE MOST COMMON PROBLEMS ENCOUNTERED WHEN INSTALLING RBBS-PC 48 8. PLANNING YOUR USER INTERFACE 50 8.1 Menus Shown to Callers 8.2 Subsystem Prompts Shown to Callers 51 8.3 Commands Available to Callers 8.4 RBBS-PC's "Wrap-around" Command Search 52 8.5 How to Have a Single Universal Command Line 8.6 RBBS-PC's Programmable User Interface (PUI) 55 8.6.1 An Example Using PUI 8.6.2 How to Implement PUI 56 8.7 RBBS-PC's Support of Sub-menus 59 8.7.1 How to Implement Sub-menus 61 8.8 RBBS-PC's "Macro" Command Support 8.9 RBBS-PC's "Smart" Text Files 63 8.10 "Colorizing" the RBBS-PC User Interface 65 8.11 RBBS-PC's Automtaic Operator Page Option 68 9. PLANNING ON HOW TO UNIQUELY IDENTIFY CALLERS 69 9.1 How to Set up Identifying and Individuation Fields 70 9.2 Preloading Identities for Instant Access 71 RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 3 of 232 TABLE OF CONTENTS (continued) Page ----------------------------- ---- 10. RBBS-PC'S AUTOMATIC SUBSCRIPTION AND TIME MANAGEMENT SYSTEM 72 10.1 Setting it Up 73 11. USING THE "CONFIG" UTILITY TO CUSTOMIZE RBBS-PC 73 11.1 Global RBBS-PC Parameters (Part 1 of 3) 74 11.2 Global RBBS-PC Parameters (Part 2 of 3) 76 11.3 Global RBBS-PC Parameters (Part 3 of 3) 78 11.4 RBBS-PC System Files (part 1) 80 11.5 RBBS-PC System Files (part 2) 83 11.6 Parameters for RBBS-PC "Doors" 85 11.7 Parameters for RBBS-PC's Security (part 1) 86 11.8 Parameters for RBBS-PC's Security (part 2) 88 11.9 Parameters for Multiple RBBS-PC's/Conferences 92 11.10 RBBS-PC SYSOP Utilities 94 11.11 Parameters for RBBS-PC's File Management System 95 11.12 Communications Parameters (part 1) 98 11.13 Communications Parameters (part 2) 102 11.14 Parameters for RBBS-PC NET-MAIL 103 11.15 New Users Parameters 105 11.16 Use of the Library Sub-System 106 11.17 RBBS-PC Parameters for Color 107 12. THE HAYES MODEM SWITCH SETTINGS AND CONSIDERATIONS 107 12.1 Hayes Smartmodem 1200 Switch Setting Considerations 12.2 Hayes Command's Considerations 108 12.2.1 Command to Reset the Modem 109 12.2.2 Command to Initialize the Modem 12.2.3 Command to Count the Number of Rings 110 12.2.4 Command to Answer the Phone 12.2.5 Command to Take the Phone Off the Hook 12.2.6 Commands to Initialize Smartmodem 2400 Firmware 111 12.2.7 Commands to Initialize Smartmodem 9600 Firmware 112 13. RBBS-PC's FILE MANAGEMENT SYSTEM 113 13.1 Multiple Directory Format 114 13.2 The Single FMS Directory Format 115 13.3 Advantages and Disadvantages of FMS over Multiple Directories 13.4 Creating the FMS Directory 117 13.5 Defining the FMS Category Codes 119 13.6 The "Library" Subsystem, CD-ROM, and FMS 120 13.6.1 How the "Library" Subsystem Works 122 13.6.2 The "Library" Subsystem and PC-SIG's CD-ROM 123 13.7 Creating the Personal Files Directory 123 14. SETTING UP ".BAT" FILES FOR RBBS-PC 127 15. THE USE OF RBBS-PC "DOORS" 128 16. THE SECURITY FEATURES OF RBBS-PC 132 16.1 RBBS-PC's Security Features 16.2 Examples of Uses for RBBS-PC's Security System 133 RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 4 of 232 TABLE OF CONTENTS (continued) Page ----------------------------- ---- 16.3 How to Implement the Password File 134 16.4 How to Implement the Security for Download Files 137 16.5 How to Implement the Security for RBBS-PC Commands 139 16.6 Beware of the "Trojan Horse" 140 17. SYSOP FUNCTIONS 141 17.1 SYSOP Commands Within RBBS-PC 17.2 SYSOP's Use of Function Keys 143 18. MESSAGING WITHIN RBBS-PC 145 18.1 The Differences Between "Conferences" and "Sub-boards" 18.2 How to Make a "Conference" or "Sub-board" Successful 148 18.3 How to Set Up a "Conference" or "Sub-board" 18.4 How to Establish a "Conference" or "Sub-board" SYSOP 149 19. AUTOMATICALLY NOTIFYING CALLERS THAT THEY HAVE MAIL WAITING 150 20. RBBS-PC's QUESTIONNAIRE FACILITY 151 21. RBBS-PC's Standard Interface for Protocol Drivers 154 21.1 Parameters passed to a protocol driver 155 21.2 Calling external protocols using "templates" 158 21.3 Parameters returned by a protocol driver 160 21.4 The protocol drivers available for RBBS-PC 22. UPLOADED FILE TIPS 162 23. DUE WARNING AND SYSOP'S LEGAL LIABILITY 162 24. COMPILING AND LINKING RBBS-PC 163 24.1 Compiling CONFIG and RBBS-PC 164 24.2 LINKing CONFIG 165 24.3 LINKing RBBS-PC 25. LIMITED LICENSE 166 26. LIMITED WARRANTY 166 27. UPGRADING FROM CPC16-1A TO CPC17-1A 166 28. PROPOSED AGENDA FOR A NATIONAL SYSOP CONFERENCE 167 29. RBBS-PC, THE LARGEST SOFTWARE HOUSE IN THE WORLD 169 RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 5 of 232 TABLE OF CONTENTS (continued) Page ----------------------------- ---- APPENDICES: A -- RBBS-PC Record Formats 171 B -- RBBS-PC in a DESQview Environment 176 C -- RBBS-PC in a MultiLink Environment 180 D -- RBBS-PC in a CORVUS Network 182 E -- RBBS-PC in an ORCHID or AST PCnet Network 183 F -- RBBS-PC in an Alloy PC-Slave/16 Environment 185 G -- RBBS-PC and 10-NET Network 191 H -- RBBS-PC and the Hearing-Impaired 192 I -- RBBS-PC and the IBM PCjr 193 J -- RBBS-PC Subscription Service 195 K -- RBBS-PC National Listing Service 196 L -- RBBS-PC and the Ark-Paradyne Modem Switch Settings 197 M -- RBBS-PC and the Anchor Signalman Express (MK12) 200 N -- RBBS-PC and the Everex 2400 Modem Switch Settings 201 O -- RBBS-PC and the Promethus 2400G Modem Switch Settings 202 P -- U.S. Robotics Courier 2400 and HST Switch Settings 203 Q -- RBBS-PC and the FASCTOMM 2496 Turbo Modem 205 R -- RBBS-PC and the ZOOM Modem HC2400 207 S -- RBBS-PC and the AT's RS-232 Cable 208 T -- RBBS-PC and BASIC Compiler Patches for "Doors" 209 U -- Using RBBS-PC to access Data Bases Remotely 213 V -- Using RBBS-PC with SeaDOG to access FIDO-NET 217 W -- DOS Limitations on Running Program Remotely 221 X -- Using RBBS-PC with DoubleDOS 222 Y -- Recompiling RBBS-PC to Reduce Memory Requirements 224 Z -- RBBS-PC and the MICROCOM AX\9624c Switch Settings 226 AA -- RBBS-PC and the Leading Edge Series L 2400B Modem 227 CONFIG Parameter Cross-Reference Index 228 RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 6 of 232 1. INTRODUCTION --------------- RBBS-PC is a Remote Bulletin Board System for the IBM personal computer, hence the name RBBS-PC. RBBS-PC has two fundamental purposes -- A. to be a catalyst for the free exchange of information, and B. to serve as an educational example of what can be done with BASIC. I distribute RBBS-PC under the trademark "Userware" because RBBS-PC is the sure and present proof that software which is shared becomes better than it was. RBBS-PC is the result of many thousands of man-hours of effort and is what it is today because of the many software contributions and suggestions by members of the Capital PC Users Group and others. Everyone has something that they believe strongly in. For me it is the "Userware" concept and the free exchange of information. As John Naisbitt states in his book, MEGATRENDS, "...the new source of power is not money in the hands of a few, but information in the hands of the many." For this reason I have devoted the time I have in writing, maintaining, and enhancing RBBS-PC over the years. The reason that I am the registered copyright owner of RBBS-PC and grant the limited license that I do is to primarily insure that these purposes are not abrogated. 1.1 The Capital PC Users Group ------------------------------ Because the fundamental purposes of RBBS-PC and the Capital PC User Group are similar, each new version of RBBS-PC is initially sent to the CPCUG's Software Exchange for distribution. CPCUG is a Maryland Corporation whose "legal name" is the Capital PC User Group Inc. The CPCUG is an all-volunteer, non-profit organization according to Section 501C3, Social Welfare, of federal law. All revenues are re-invested in and applied toward CPCUG's education programs. 1.2 The "contributions" requested for RBBS-PC ---------------------------------------------- The "contributions" requested for RBBS-PC can be one of four types: A. Modifications to RBBS-PC, itself, that are documented and distributed as .MRG files against the "base-line" source code that other SYSOPs might elect to incorporate into their version of RBBS- PC (remember RBBS-PC can not be distributed in modified form with violating both the RBBS-PC copyrights and the limited license granted with it's use). B. Publicly distributable software. It can either be "public domain" (i.e. software which the author has relinquished all rights and which may be appropriated by anyone for use in any way), or publicly distributable software (i.e. software in which the author has retained his rights and which may only be used according to the conditions under which the author has designated). RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 7 of 232 C. Equipment or services. Be inventive in light of the CPCUG's objectives under 1.1. If you or your organization can donate equipment, software, supplies, or services to the CPCUG, feel free to do so. If you are so inclined, but before you do so, contact the Capital PC User Group, 51 Monroe Street, Plaza East Two, Rockville, MD 20850. For general information about the appropriateness of the bequest, contact the Capital PC User Group directly at (301) 762-6775. D. Money - the last level of "contribution". Money is the one commodity that we are willing to exchange among each other without first having obtained the respect, consideration, etc. of the other party. It is perhaps the easiest to give as it exonerates us from the other levels of "contribution." CPCUG is an all volunteer organization and, of course, money is seldom plentiful. However the essence of CPCUG is the time, ideas, and effort that each of the volunteers contribute to it. For this reason, while money is always appreciated, money is not the best or even the second-best type of "contribution" you could make. Independent of any donations of enhancements to RBBS-PC, publicly distributable software, equipment, services, supplies, or money, consider becoming a CPCUG member. Simply send your name, address, and phone number along with $35 to CPCUG, 51 Monroe Street, Plaza East Two, Rockville, MD 20850 or call their membership hot line at (301) 670-1737. If in the final analysis you feel that you can do none of the above, o remember those who have, o enjoy what they have nurtured, and o keep the faith with those who have gone before you. 1.3 The "history" behind RBBS-PC -------------------------------- Electronic bulletin board systems have been around ever since personal computers existed. The first ones were very primitive and usually consisted of some posted notices and maybe allowed for on-line messages. It must be remembered that the IBM PC was only announced in August of 1981 and first became available in October of 1981. Therefore it is not surprising that the early history of BBS' is associated with non-IBM personal computers. The "early history" of bulletin board systems began around 1978 in Chicago with the CBBS/Chicago (Computerized Bulletin Board System/Chicago). It was created by Ward Christensen and Randy Suess -- members of the Chicago Area Computer Hobbyist Exchange (CACHE). CBBS for the CP/M is written in 8080 Assembler language (11,000 lines of it) and, like the early versions of RBBS-PC (i.e. prior to CPC12-5A), detects the baud rate and the parity of the user when he first signs on from the three carriage returns that the user must enter. About the same time, Bill Abney wrote a BBS for the Radio Shack TRS-80 Models I and II called Forum-80. RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 8 of 232 The earliest BBS that I know of was written for the Apple (who else had personal computers in those days?) called the "Apple Bulletin Board System" (ABBS). It was written by Craig Vaughn and Bill Blue. They later created another bulletin board system for the Apple II called the People's Message System (PMS). Another Apple bulletin board system that came into being was for the Apple II, II+, and IIE as well as the Franklin Ace and it was called the CommuniTree. It was written in the FORTH language by Dean Gengle and several others. When IBM announced its first personal computer, the IBM PC, in August of 1981, there was no BBS for it. In the summer of 1982, Brad Hanson found a prototype version written by Russ Lane in IBM's BASIC on David Crane's Dallas RCP/M\CBBS system. Brad added many fixes and modifications. In the first half of 1983, many members of the Capital PC Users Group's Communication Special Interest Group (SIG) such as Larry Jordan, Rich Schinnell, Gary Horwith, Jim Fry, Scot Loftesness, and Dorn Stickle further enhanced it and added XMODEM file transfer capability until it became known as RBBS-PC CPC 09 in May of 1983. At that time each feature or modification was identified by a new version number; it still ran only under the BASIC interpreter; and was both relatively slow (because of the interpreter) and somewhat unstable (it would normally "crash" at least once each day). Late in May of 1983, I asked Rich Schinnell if there was any "bulletin board" software available for the IBM PC written in BASIC. Rich told me to give Larry Jordan a call. Larry said that he was just getting CPC09 ready to send to Rich Schinnell who at that time was Director of the Capital PC User Group's Public Domain Software Library and that I could get it from Rich. I did, and still have the diskette just as Rich sent it to me -- dated June 22, 1983. Bulletin board systems, historically were the result of a single person or small group of persons' efforts and tended to serve a very narrow interest group -- typically those interested in the medium itself (i.e. PCs, programming, communications, etc.). This was true up to and including RBBS-PC CPC09. In fact, most of the incentive to get the public domain versions of RBBS-PC (CPC09 and earlier) functioning was to introduce the XMODEM protocol to the IBM PC-based community. In this CPC09 was successful and may have been the primary incentive for XMODEM to be included in PC-TALK at all. Since June of 1983 I have authored and released THIRTY versions of RBBS-PC and distributed them exclusively through the Capital PC User Group under the limited license described in section 25 of this documentation. At this time RBBS-PC appears to have become the "industry standard" for IBM-type personal computer bulletin board systems. However, even from the very beginning BBSs have excelled whenever: a.) there was a geographically dispersed audience, b.) with a need to exchange highly complex/technical information, c.) in a timely and accurate manner. RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 9 of 232 RBBS-PC's impact has been to open an entirely new medium of communications between people. Rather than as an end in and of itself, RBBS-PC has come to serve as a means to an end -- the free exchange of ideas. On a technical level it is certainly an example that shows "real programmers can/do program in BASIC." I would like to think that RBBS-PC had something to do with IBM and Microsoft coming out with new versions of the BASIC compiler that support communications, sub-routines, local and global variables, file-locking in a networking environment, etc. RBBS-PC represents a fundamental cornerstone, not just a phase, in what can be viewed as a "social renaissance." The three areas that I mentioned earlier in which bulletin boards excel seem to ebb and flow within communities and organizations. RBBS-PC provides an almost instantaneous mechanism by which these needs can be met. Many of the Big 8 accounting firms bring up RBBS-PC's just to fulfill one contract so that the various geographically disbursed members on the contract can communicate across time zones and continents. Unlike radio, newspapers, and television -- RBBS-PC provides a vehicle within which information can be EXCHANGED! That is what makes RBBS-PC so unique. Because the exchange is written, it is structured. Because it is structured, it can be thoughtful. The "social renaissance" that RBBS-PC represents is the electronic elimination of those barriers that had previously inhibited the "exchange" of information within our society. RBBS-PC provides every personal computer owner with his own "soap-box" in a national Hyde Park. Previously the channels of communication had built-in barriers to "exchange"; with RBBS-PC those barriers begin to cease to exist. While only the most fanatical RBBS-PC trivia experts may be interested, I've gone back and checked all the documentation and releases of RBBS-PC that I've authored and here is the tedious chronology: RBBS-PC Initial Major Enhancements Version Release Number Date CPC10.0 07/04/83 RBBS-PC first written to be compilable by IBM's BASIC compiler, version 1.0 CPC11.0 08/10/83 RBBS-PC restructured so that all parameters were external (i.e. in the RBBS-PC.DEF) allowing SYSOPs who didn't want to spend the $300 for the BASIC compiler to tailor RBBS-PC to their taste. CONFIG.BAS was first written to generate RBBS-PC.DEF. CPC11.1 09/15/83 Jon Martin contributed UTSPACE.OBJ, a sub-routine that allowed the compiled version of RBBS-PC to determine the amount of free space available for uploading. CPC11.2 10/01/83 The error trapping within RBBS-PC was completely re- written to be more comprehensive. CPC12.0 10/28/83 Tree-structured file directories and the ability to detect that RBBS-PC was in a "MultiLink" environment RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 10 of 232 RBBS-PC Initial Major Enhancements Version Release Number Date were incorporated. "MultiLink" is a product of the Software Link, Inc. which allows DOS 1.1, 2.0, 2.1, 3.0 and 3.1 to be "multi-tasking." CPC12.1 12/18/83 The ability for a SYSOP who signed on remotely to drop (Versions into DOS was added. Also the "New" command was added "A" to "F") that allowed users to determine what new files had been made available since the last time they were on. CPC12.2 04/08/84 The security system designed by Ken Goosens was (Versions incorporated. RBBS-PC's security system has an elegance "A" to "D") unmatched even by the largest mainframe. Essentially the security system designed by Ken is "self-locking lock" and, even though RBBS-PC's source code is distributed, it's security system has remained unbroken. Of course, SYSOPs who didn't adhere to RBBS- PC's security structure have had their system "crashed" and every SYSOP should operate as if the very next caller could crash his system. CPC12.3 11/11/84 This was almost as complete and as major a re-write of (Versions RBBS-PC as CPC10.0 had been. Beginning with CPC12.3 up "A" to "B") to nine RBBS-PCs can share the same files in either a multi-tasking DOS environment (i.e. MultiLink from the Software Link, Inc.) or in a local area network environment (i.e. Corvus or Orchid). CPC12.4 03/10/85 RBBS-PC's stature in the industry became recognized (Versions when, as author of RBBS-PC, I was granted a license by "A", "A1", Microcom to incorporate their proprietary MNP protocol and "B") into RBBS-PC. Almost at the same time many manufactures recognized the institution that RBBS-PC had become in our industry and elected to include "RBBS-PC compatibility" in their minimum criteria for the introduction of their new products. RBBS-PC's Vendor Support Program is more fully explained in the RBBS-PC documentation but one direct result of this was the introduction of 300/1200/2400 BAUD support in CPC12.4A before most such modems were generally available. CPC12.5 07/14/85 RBBS-PC was enhanced to allow 36 copies of RBBS-PC to (Versions share the same files in a network environment. RBBS-PC "A" to "B") automatically answers the phone and no longer requires each caller to enter up to 3 carriage returns in order for RBBS-PC to detect the users baud rate and parity. Logon to RBBS-PC has been made much more efficient with the USERS file no longer being searched sequentially and the MESSAGES file no longer being read three times. Version CPC12-5B, released August 25, 1985, WAS THE LAST VERSION COMPILABLE BY VERSION 1.0 OF THE IBM BASIC COMPILER! RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 11 of 232 RBBS-PC Initial Major Enhancements Version Release Number Date CPC13.1 12/01/85 RBBS-PC was completely rewritten for both the Version (Version 2.0 of the IBM BASIC compiler ($495 list price) and "A") Microsoft's QuickBASIC Version 1.0 ($99 list price). XMODEM with CRC was added as a file-transfer protocol as well as the ability to display on the color monitor of the PC running RBBS-PC the color/graphics that the remote user sees exactly as he sees them. CPC14.1 03/16/86 RBBS-PC's internal structure was split into two parts - (Versions - a RBBS-PC.BAS for the main-line source code and logic "A", "B", and a RBBS-SUB.BAS for commonly called subroutines. "C", and This allows unlimited growth for RBBS-PC by providing "D") multiple "code segments" within RBBS-PC. Support for on-line questionnaires, auto-downloading, and the Columbia University-sponsored KERMIT RBBS-PC Version protocol were also included as well as the option to utilize assembly language subroutines to increase for better performance over their BASIC counterparts. CPC15.1 03/15/87 RBBS-PC's internal structure continued to become significantly more modularized and structured. Major enhancements included a File Management System for directories, additional file exchange protocols, support for managing subscriptions, the ability to run as a local application on a network, configurable command letters, the ability to use any field or to define a new field to identify callers, the ability to individuate callers having the same ID, multiple uploads on a single command line, new A)nswer and V)erbose ARC list commands, context sensitive help, and a new subsystem for software "libraries". CPC16.1 03/27/88 RBBS-PC's internal structure continued to become (Version significantly more modularized and structured. Major "A") enhancements included the addition of "sub-boards" (i.e. conferences with there own bulletins, file areas, menus etc.), a programmable user interface, the capability to have SYSOP-written "sub-menus" for any command, the ability to hang off of a public data network such as Compuserve's as a "node", the incorporation of "personal downloads" (i.e. files only specific individuals could list/download), the ability to vary the amount of time a user has on the system by the time of day the user logs on, the capability of preventing any message (public or private) from being read until the SYSOP has reviewed it, an enhanced CONFIG utility with many more options, YMODEM protocol built-in to RBBS-PC's main-line source code, the ability to automatically add users to conferences, and support for The Software Link's MultiLink Version 4.0. Despite all RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 12 of 232 RBBS-PC Initial Major Enhancements Version Release Number Date these enhancements, the BASIC RBBS-PC code was significantly enhanced such that it only requires 268K to run -- allowing two copies to run in multi-tasking DOS environments that have 640K available. CPC17.1 10/02/88 RBBS-PC's internal structure continued to become (Version significantly more modularized and structured. Major "A") enhancements were made in the System Support area with the support for up to eight communications ports; built-in interfaces to external communications drivers based on Vince Perriello's "FOSSIL" driver concepts; automatic notification of the SYSOP when specific users log on; improved automatic invocation of other applications based on time of day; and SYSOP-selectable time delays that users must wait before being able to download or exit to a door. RBBS-PC's unique programmable user interface (PUI) was enhanced to support "macros" (i.e. use a single command to invoke any number of RBBS-PC commands); SYSOP-selectable colors for all prompts and messages (i.e. "colorization"); caller-selectable "colorization" for text (i.e. color, bold or normal, highlighting of text, etc.); and personalized text files (i.e. text files that can dynamically adapt to include information unique to each caller). The messaging within RBBS-PC was enhanced to notify each caller that logs on of the number of new messages and how many are addressed to the caller for the conferences to which the caller belongs. The text editor function for messages was enhanced to allow any character to be edited. RBBS- PC's standard "threaded" message search now also scans the text of the messages for matches. The RBBS-PC file subsystem was also significantly enhanced to include an unlimited number of installable protocols; batch downloading for such protocols that support this (i.e. Zmodem, Megalink, and Sealink); and control of callers ability to download based on either the number of characters or the ratio of the callers downloads to uploads. During the evolution of RBBS-PC I have had the distinct privilege of working with many contributors. Contributions have ranged from suggestions, to software fixes, to significant enhancements, to improved documentation. Some of the individuals named here have continued their contributions to RBBS-PC even to the current release. Others have gone on to pursue other interests. Where they are now, for the most part, I do not know. Whether they have become heroes or villains, it is not important. None should be forgotten. In their contributions to RBBS-PC's on-going growth, each has paused to give of themselves without hope of reward by practicing RBBS-PC's fundamental principle -- "users helping users." For those who became less than they were, they should be remembered for what RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 13 of 232 they contributed. For those who have became more, I am continually reminded that RBBS-PC has granted me the privilege of walking in the company of giants. While I have met very few of these people personally, those whose names I remember are: Doug Azzarito John German Kevin Lutz Andrew Silber Jeff Batdorf Read Gilgen Matt Malden Gregg Snyder Rod Bowman Ken Goosens Carl Margolis Robert Snyder Randy Brodersen Ray Gwinn Jon Martin Carl Spencer Mike Brown Dave Hacquebord Robert Mahoney David Staehlin Sam Brown Steve Harrison Sidney Markowitz Stan Staten Mike Button Gary Hoff Louie McCaw Dorn Stickle Vince Castelli Gary Howrith Wes Meier Terry Steichen Rob Cecchino Charlie Innusa John Morris Randy Sun Tom Collins Loren Jones Bill Newkirk Yew Seng Tan Drew Commins Larry Jordan Jeregen Nordhausen Terry Taylor Ezra Conger Robert Jueneman Vince Perriello Jan Terpstra Ed Copley Vern Kallegin Harvey Pierce David Terry Richard Couture Dave Kleinschmidt Danny Plunkette Arnold Thomsen Bob Crammer Steven Kling Lee Pollard Daan van der Weide Dave Crane Ronald Koridon Jeff Porter Rick Wadowski Everett Delano Steve Lieber James Reinder Clark Walker Peter Eibl Steven Linhart Kurt Riegel Kim Wells Warren Fox Joseph Lionelle Joel Ricketts Bob Westcott John Friel Scott Loftesness Jacques Rodrigue Robert White Jim Fry Harry Logan Dick Rohradnz Asa Fulton Gene Lowry Rich Schinnell Kent Galbraith James Ludwick Mark Seiden Mitch Geier Special thanks goes to SYSOPs who helped sponsor enhancements to RBBS-PC, including Ken Rogers of the United States Department of Commerce ECONOMIC BULLETIN BOARD who encouraged configurable identification and individuation, Loren Jones of the The Center for Law and Computers at the Illinois Institute of Technology's Chicago-Kent College of Law who contributed to subscription support, John Rittwage of the American College of Obstretricans and Gynecologists who helped support submenus and the programmable user interface, and Brian Kelly of National Credit Appraisals and Reporting, whose special needs prompted the development of personal downloading. To those whose names have not been mentioned -- apologies are extended Take comfort in knowing that you live on in the work that you have wrought. Jon Martin is primarily responsible for whatever technical excellence that exists in RBBS-PC -- including the ability to have multiple RBBS-PC's share the same files. I am not a programmer and didn't even know BASIC until I started writing RBBS-PC in June of 1983 and released RBBS-PC CPC10.0 in July of 1983. Jon's commitment to RBBS-PC has at least matched my own. Despite my own ineptness, Jon's patience, understanding, and technical insights have been unfailing over these several years and, I would like to both publicly acknowledge his contributions to RBBS-PC and express my RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 14 of 232 appreciation for his efforts on behalf of RBBS-PC. I'd also like to mention Ken Goosens' efforts on behalf of RBBS-PC. Ken took the time and trouble to wade through the BASIC source code and incorporated the "security" system that exists within RBBS-PC today. Anyone who looked at the source code prior to release CPC12-2A can appreciate the magnitude of Ken's efforts. I wish space allowed me to chronicle the contributions of each of the contributors to RBBS-PC. In an age of cynicism, RBBS-PC and the Userware concept represents an opportunity for each of us to give back to the world something a little better than when we found it. As I said in section 1, this is something that I believe in strongly. To each of the contributors to RBBS-PC I would like to say personally "I am very proud of the company that RBBS-PC keeps." All changes to RBBS-PC since CPC10.0 have been "ADDITIVE, meaning that all capabilities in earlier versions are retained in the later versions. 1.4 RBBS-PC Update Conventions ------------------------------- RBBS-PC continues to evolve and be "debugged." The following coding conventions have been helpful in the past and you are requested to observe them in the future: Updates consist of two types of ASCII files. One called xxxxxx.MRG which are the BASIC source statements for the particular base-line source code component of RBBS-PC to be updated. The lines that have been modified are indicated as being so modified with a comment beginning in column 70 in the format as follows: 4330 QUICK.SCAN.MESSAGES = FALSE ' CPC14-1D These .MRG files can be applied to the base-line source code via Ken Goosens Batch Line EDitor utility program (BLED). The BLED utility can easily create .MRG files as it has both a file compare and file merge function that is specifically geared to the new BASIC compiler's capabilities that allow lines of source to be unnumbered. The second file type is called xxxxxx.DOC. It describes on a line-by-line basis the specific functions added or bug that was fixed. Obviously xxxxxx can be anything you wish to name it. The second type of file is what allows me to integrate several .MRG files and resolve whatever conflicts that may exist. The RBBS-PC naming conventions of CPCxx.x are roughly as follows: 1. If a "bug" is being fixed CPCxx.x will be given a .MRG file name such as CPC14-1D.MRG with a corresponding CPC14-1D.DOC file describing the changes. The first version of CPCxx.x is always "A". When you logon to RBBS-PC the version will be displayed. RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 15 of 232 2. As bugs are reported and fixes found for the current release of RBBS- PC, the source code corrections are distributed via an RFIXmmdd.ARC file. This contains the necessary files to apply the "temporary fixes" against the released version of the source code and re-compile the source code. The recompiled .EXE files are distributed via a file named RFIX-EXE.ARC. 3. If a new feature or enhancement is added the last digit in the CPCxx.x will be incremented by one (i.e. CPC12.2D was followed by CPC12.3A). 4. If a significant change to source code or logic occurs, the first two digits of the release level will change (i.e. CPC14.1 was followed by CPC15.1) The purpose of these conventions is to allow everyone to know what RBBS-PC level they are running under (users as well as SYSOPs) and understand the logic behind the changes/fixes as they occur so each SYSOP can evaluate them for his own needs. If you have comments or fixes please let me know so that they can be reflected in the RBBS-PC program and shared with all other users. You can do that by sending your changes by mail to: D. Thomas Mack 39 Cranbury Drive Trumbull, Conneticut 06611 or uploading the changes to either of my RBBS-PC lines -- (203) 268-5315 or (203) 268-0129. While comments and suggestions are always welcome, those that are accompanied by the RBBS-PC source code changes that implement them carry a lot more weight than those that don't. 1.5 Beta test sites, Where and Why ----------------------------------- Many people volunteer to be "beta test" sites. It is fitting that those who do know why each release of RBBS-PC is "beta tested" and what it takes to be "beta test" site. The "beta test" process seeks to put each new release in as varied as an environment as possible in order to resolve bugs in the new features as well as assure that old bugs are not re-introduced by the addition of new features. Beta testers take professional pride in what RBBS-PC is -- the bulletin board standard for the IBM PC industry. Every beta tester recognizes their responsibility to those who have contributed to RBBS-PC and assumes the obligation of not letting them down by putting out a shoddy product. There are essentially only 13 criteria for becoming a beta test site: 1. A commitment to the "Userware" concept and the free exchange of information. 2. A demonstrated knowledge of RBBS-PC's source code. 3. A willingness to work within the confines of the BASIC language. 4. A determination to avoid eliminating earlier functionalities within RBBS-PC -- only add new ones. 5. A system on which unmodified versions of the new beta test version RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 16 of 232 of RBBS-PC will be run. 6. Being unwilling to release any part of what is being beta tested to anyone else. 7. Accepting the risk of having your entire system and hard disk be vulnerable to software flaws in the version of RBBS-PC being beta tested. 8. Being willing to FIX the bugs you encounter -- simply reporting them is not enough! 9. Living with the bugs that aren't fixed until they are fixed. 10. Being willing to call and discuss problems via voice (at your expense -- not mine). 11. Being willing to call and download (almost daily during the "beta test" period) 450K files also at your expense. 12. Living with the fact that whatever you are beta testing is not going to be what is actually released and that you will probably have to download what is actually released just like every one else. 13. Being charitable about the author's programming skills. Of all the criteria, it is the first one that is often the most difficult requirement for those who would be "beta testers" to accept. The commitment to the "Userware" concept requires that contributors to RBBS-PC insist on accepting neither personal recognition, monetary reward, nor benefit for their contributions -- except the self-satisfaction in knowing that whatever they contributed made RBBS-PC (and hopefully) the PC world better than it might otherwise have been. RBBS-PC does not exist to be a means to some individual's personal gain or ego gratification. Too many people have contributed too selflessly of themselves to RBBS-PC for this to ever be allowed to happen. For those for whom this is too difficult a requirement, RBBS-PC's totally open architecture provides the .MRG/.DOC mechanism (documented in section 1.4) to allow individual authors of software modifications to RBBS-PC to both achieve individual recognition and monetary reward from those RBBS-PC SYSOPs who want to incorporate such merges and features into their versions of RBBS-PC. Please note that distribution of .MRG and .DOC files is totally consistent with the limited license that is granted with RBBS- PC. Also note that distribution of modified versions of RBBS-PC is in violation of RBBS-PC's limited license agreement. Needless to say, those few who participate in each new release of RBBS-PC typically are not the same people from release to release. This is because of the intensity and time that the beta test period makes on the beta testers. Another constraint is my abilities to adequately respond to more than two or three beta testers at most. Finally, like owning a swimming pool or a boat, everyone wants to be a beta tester once! There is little glory and lots of pain. Jon and I usually divide up the beta testing based on who lives east and west of the Mississippi river in order to have as many beta test sites as possible. Ken has beta test sites all over the United States. Most of the credit for RBBS-PC CPC17-1A being better than the earlier versions goes to the following beta testers: RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 17 of 232 Doug Azzarito, Palm Beach Gardens, Florida Rod Bowman, Alta Loma, California Mike Brown, Madison, Wisconsin Paul Cangialosi, Woodbury, N.Y. Juan Davila, Rio Piedro, Puerto Rico Andrew Hoag, Fargon, North Dakota Dave Hacquebord, Tampa, Florida Loren Jones, Chicago Illinois Steven Kling, Brentwood , Maryland John Krytus, Northwook, Ohio Ron Kurr, Atlanta, Georgia Terry Leckbee, Kansas City, Kansas Gene Lowry, Tuscon, Arizona Alex Mondale, Washington, D.C. Willie Moore, Birmingham, Alabama Tadas Osmolskis, Silver Spring, Maryland Lee Pollard, Oxon Hill, Maryland Lyndon Payne, Plano, Texas Malcom Ramsay, Roswell, Georgia Steve Rogers, Lincoln, Nebraska Jose Sanchez, Gaithersburg, Maryland RoseMarie Siddiqui, Fairfax, Virginia Phil Simerly, Chantilly, Virginia Ray Smith, Carrollton, Texas Greg & Bob Snyder, Burke, Virginia Stan Staten, Gaithersburg, Maryland Terry Taylor, San Leandro, California Rick Wadowski, Clinton Twp, Michigan Kim Wells, Largo, Maryland 1.6 An Example of "Users Helping Users" --------------------------------------- The ability to have multiple RBBS-PC's running concurrently -- either on a single PC in a multitasking DOS environment or in a local area network, is a concrete example of the concept of "users helping users" in action. This ability was developed in support of the efforts of the State of West Virginia Department of Education's "West Virginia Microcomputer Educational Network" project. It is the first statewide microcomputer network and encompasses all of the state's 1,125 schools in 55 different school districts. Each school is intended to have the capability of accommodating up to twenty IBM PC's in a local area network sharing a common 20MB disk drive. As of June of 1984, 83 of the 1,125 schools had such networks. Each PC can communicate with either the LAN, a central library, or with other schools in order to share programs and materials. The key component for this communication is RBBS-PC. In a presentation at the U.S. Department of Education in Washington, D.C. on June 22, 1984, the role RBBS-PC plays was described as follows: "The medium that ties the entire system together -- that allows for communication not only between one school and another but also between schools and the central library -- is an electronic bulletin board (RBBS-PC) This bulletin board will be in operation 24 hours a day at the central site, with a similar bulletin board in operation at every school. RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 18 of 232 The local school bulletin board (RBBS-PC) could be accessed by students who wish to review their lesson or take a test at home provided they had a computer and a modem. Teachers could access their grade book or other reports and lessons at home in preparation for the next school day. Neither bulletin board system (RBBS-PC) requires personnel to answer telephones or transmit files. They are both totally unmanned and operate 24 hours a day. No toll charges, of course, would be assessed for calling the local school bulletin board and toll free 800 numbers are used for accessing the central library." The State of West Virginia arranged to have the vendors involved, IBM and Corvus, make the appropriate equipment available on a "loan" basis so that RBBS-PC could be developed to work in a local area network environment. Since this project conformed so closely to the primary objectives of RBBS- PC, we agreed to volunteer our time and take on the task of enhancing RBBS- PC to allow up to nine (9) copies of RBBS-PC to execute concurrently sharing many of the same files. On a single PC the maximum number of concurrently running RBBS-PC's within the same DOS is limited only by: a. the number of communications ports installed on the PC. IBM's limit is two (COM1 and COM2), but other vendors supply "add-on" cards that provide for up to eight or more communications ports on a single PC. b. the number of communications ports that the BASIC compilers can read and write to -- currently (COM1 and COM2). IBM expanded the number of communication ports available for the PS/2 models running PC-DOS 3.3. RBBS-PC, beginning with CPC17-1A, can support additional communications ports using FOSSIL drivers (see CONFIG parameter 221). c. the number of concurrently running tasks that can be supported. IBM's DOS is limited to one task. Other vendors provide "add-on" software to IBM's DOS that provides for up to nine simultaneous tasks. Within a network environment (i.e. multiple PC's linked together sharing the same devices) the maximum number of concurrent RBBS-PC's is set by RBBS-PC's internal design to nine (9). This design was based on the fact that anyone who wanted to run nine RBBS-PC's sharing the same set of files would take the $46,000 needed to buy nine PC's with modems, network interface cards, hard disk (at least 20MB) and purchase a minicomputer for the same amount of money with more ports and storage. CPC13-1A was updated to allow for 36 RBBS-PC'S to share the same files. For those interested in further information on the State of West Virginia's Microcomputer Educational Network, please contact: Mr. John E. Cook State of West Virginia Department of Education 1900 Washington Street East Building 6, Room 221, Capital Complex Charleston, West Virginia 25305 RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 19 of 232 2. Summary of RBBS-PC's Features -------------------------------- During the past five years RBBS-PC has received many accolades. PC World says "For electronic mail and bulletin board applications, the RBBS-PC software is the best choice." EDP Analyzer says "RBBS-PC is the easiest to use." RBBS-PC was the origin of PC Magazine's "Interactive Reader Service." PC Magazine writes that RBBS-PC "is one of the most popular BBS programs for the IBM PC" and has called RBBS-PC "an industry standard." INFOWORLD, in a comparison of the most popular PC-based bulletin board systems rated RBBS-PC the highest. Almost as if in confirmation, the U.S. Department of Commerce's National Bureau of Standards report on Electronic Bulletin Boards (publication NBSIR 86-3356) is devoted entirely to RBBS-PC. RBBS-PC CPC17-1A is a significant enhancement to RBBS-PC and will be the 32nd release of RBBS-PC CPCxx since I first published it in July of 1983. RBBS-PC's policy of freely distributing the source code and continually expanding it's range of capabilities throughout these last five years represents not only the very best that is embodied in the concept of "users helping users" but an expectation of excellence that NO product in the PC industry has ever even approached. Here is a brief summary of the major features of RBBS-PC. RBBS-PC is the Remote Bulletin Board System for the IBM (or compatible) personal computer. One of it's two primary purpose is to foster the free exchange of information by allowing a microcomputer to be turned into a "host" computer that people can "dial" into and use. It is a full featured Bulletin Board System that supports: o bulletins o electronic mail (public and private) o file exchange (uploading and downloading) o on-line questionnaires based on "scripts" written by the SYSOP o access to other applications from RBBS-PC (i.e. "dooring"), and o letting authorized callers drop into the operating system to run programs remotely from the caller's computer. RBBS-PC is unique among host communications programs in that it is made available under a limited license which requires that no charge for RBBS-PC be levied -- only a minimal copying fee is permitted. RBBS-PC is unique also in that ALL the source code for each release is also made available. Those who wish to make contributions for RBBS-PC are asked to contribute enhancements to RBBS-PC itself or contributions to the Capital PC User Group. The author and contributors neither ask for nor accept money for RBBS-PC. Upgrades, which average about two a year, are free. There is no extra charge for a multi-user version. In fact there is only one RBBS-PC! It can act as either a multi-user version or as a single-user system. The purpose of this section is to provide a check list of RBBS-PC's major features. After all, being free and including source code means that RBBS- PC is the "industry standard" against which systems with similar functions can be judged by end-users. RBBS-PC has been around since 1983, and many people may not realize just how extensively it has evolved and been enhanced over these last five RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 20 of 232 years. One advantage of distributing source code is that those who run RBBS-PC systems are able to contribute improvements to it. Many people have contributed to RBBS-PC over the years -- over 80 are listed in the RBBS-PC documentation itself. The check list of major features and enhancements that follows are just part of this on-going tradition. 2.1 General: ------------ Number of different "conferences" or messages areas -- unlimited Number of messages that can be left -- unlimited Number of files that can be uploaded or downloaded -- unlimited Number of bulletins that can be posted by the SYSOP -- unlimited Number of different file transfer protocols supported -- unlimited Number of external applications that can be "DOORed" to -- unlimited Number of on-line questionnaires -- unlimited Number of questions in on-line questionnaires -- unlimited Number of levels of security -- 66,536 Number of registered callers -- 32,767 Maximum number of characters in a single file -- 32,767 Maximum baud rate supported -- 19,200 Maximum number of characters in a single message -- 6,128 Maximum number of lines in a single message -- 99 Maximum number of simultaneous callers or users -- 36 Maximum number of communications ports supported on a one PC -- 8 Donation to CPCUG for a copy of RBBS-PC (4 diskettes) -- $16 Is the multi-user version included in the price -- yes Is technical support included in the price -- yes Is ALL source code distributed with each release -- yes Are fixes and patches promptly made available -- yes Is extensive technical documentation (220+ pages) including file descriptions and record layouts distributed with each release -- yes Is there an OPTIONAL -- but professionally written and published (Bantam Books ISBN 0-553-34552-4), startup guide (430+ pages) for first time bulletin board system operator (SYSOP) -- yes 2.2 Messaging: -------------- Within a conference or message area: The user's last message read is remembered -- yes A user's security level can be unique to each conference -- yes User's "preferences" (expert/novice) can be unique -- yes A user can have privileges different from other areas -- yes Conferences can be: Public (anyone can join) -- yes Private (only pre-registered users can join) -- yes Semi-private (users with sufficient security can join) -- yes RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 21 of 232 Each conference or message area can have unique or different Bulletins -- yes On-line help files -- yes Files available for downloading -- yes mixtures of commands -- yes menus -- yes "Doors" (i.e. external applications that are exited to) -- yes When callers log on they can (at the SYSOP's option) be Automatically notified of all mail waiting for them -- yes Automatically notified of only NEW mail waiting for them -- yes Automatically notified which conference has mail for them -- yes ONLY notified of mail in conferences the caller belongs to -- yes Automatically notified of the messages that they have left -- yes Automatically notified of the files they uploaded -- yes Automatically notified of the files that they downloaded -- yes Automatically notified of their profile of preferences -- yes Automatically notified of any new "bulletins" -- yes Automatically notified of any new files -- yes Immediately download files -- yes Immediately list the new bulletins -- yes Immediately go directly to a specific area (turbo logon) -- yes Specific messages can be: Public (readable by all) -- yes Private (to a specific individual) -- yes To a "group" (readable by a specific collection of users) -- yes Password protected (readable by supplying the password) -- yes Public but available to others after the SYSOP reads it -- yes Private but available to addressee after the SYSOP reads it-- yes Read by only those with a high enough security level -- yes "Quick" scanned by subject only -- yes "Quick" scanned with 69 messages displayed at a time -- yes "Scanned" by sender, addressee, date, subject, and date/ time it was received by the addressee -- yes "Scanned" with 23 messages displayed at a time -- yes Read while "quick" scanning -- yes Killed (i.e. deleted) one at a time -- yes Killed in multiples -- yes When a message is read the software provides Name of caller who entered the message -- yes Date and time the message was entered -- yes Name of caller to whom the message is addressed -- yes Date and time the message was received -- yes Subject of the message -- yes Minimum security level needed to read the message -- yes Messages can be searched via "threads" (for specific strings) By message subject only (i.e. "static" threading) -- yes By sender, receiver, subject, or (i.e. "dynamic" threading)-- yes By text within a messages (i.e. "turbo" threading) -- yes And read while threading without disturbing the search -- yes RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 22 of 232 Messages can be read Forwards -- yes Backwards -- yes Singularly, by specific message number -- yes Multiply, by specifying a series of message numbers -- yes While "static" threading (i.e. matching on subject) -- yes While "dynamic" threading (i.e. match on all header info) -- yes While "turbo" threading (i.e. match on header or msg text) -- yes That are only addressed TO the caller -- yes That are only FROM the caller -- yes Or re-read immediately after the last screen of a message has been read (useful for long messages) -- yes When entering or replying to a message The message subject can be edited -- yes The sender is notified if the addressee has not logged on -- yes The caller can see if the mail has been received -- yes After replying only the message header is displayed -- yes After replying the caller can re-read the message -- yes After replying the caller can kill the message replied to -- yes The built-in message editor has Automatic "word-wrap" -- yes Allows any character as a separator for replacing strings -- yes Text files to be uploaded remotely as a message -- yes Text files to be imported by the local SYSOP -- yes Lines to be deleted -- yes Character strings to be searched and replaced -- yes Margin widths that can be set by the caller -- yes 2.3 File System Management and Exchange: ---------------------------------------- The software automatically maintains a list of files available to callers containing: -- yes Name of the file -- yes Size of the file -- yes Date the file was created -- yes One-line description of the file -- yes Extended (multi-line) file description -- yes Unlimited number of categories in which to classify files -- yes Categories can have multiple line descriptions -- yes A file can be associated with multiple categories providing the capability of having a complex, tree classification system for files -- yes Callers can search the list of files available -- yes By category -- yes By date (most recent first) -- yes By match on a string in one-line description -- yes By match on a string in extended description -- yes By "wildcards" -- yes RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 23 of 232 Callers who upload files can be asked to: Categorize the uploaded file -- yes Provide a one-line description of the file -- yes Provide an extended description of the file -- yes Authorized callers can add file descriptions without uploading-- yes On an unsuccessful upload, the partial file is deleted -- yes Files may be made available for "personal downloads" (i.e. limited to a specific user or security level) -- yes Files that are .ARCed contents may be viewed by the caller before downloading -- yes Files may be separated into different DOS subdirectories for callers to download from -- yes The software can search 7,000 file descriptions in 60 seconds -- yes Files can be downloaded when searching the list of of files -- yes File can be downloaded when listing the file descriptions -- yes File listings can be resumed after a download -- yes Multiple file downloads/uploads can be requested -- yes The software supports a "LIBRARY" file subsystem in which: files of the same name are in different DOS subdirectories -- yes files within a single DOS subdirectory can be .ARCed together into a single file and downloaded -- yes PC-SIG's CD-ROM can be made available for downloading -- yes The software allows file transfers with both "Internal" protocols (handled by RBBS-PC source code): ASCII -- yes Xmodem (checksum) -- yes Xmodem (cylical redundancy check) -- yes Ymodem -- yes and "External" protocols (i.e. handled by separate .EXE files): Xmodem (checksum) -- yes Xmodem (cylical redundancy check) -- yes Ymodem -- yes YmodemG (used when MNP exists in the modem) -- yes Imodem (used when MNP exists in the modem) -- yes Windowed Xmodem -- yes Kermit (as defined by Columbia University) -- yes Windowed Kermit (as defined by The Source) -- yes Zmodem -- yes Zmodem (batch) -- yes Sealink (by System Enhancements Associates) -- yes Megalink -- yes RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 24 of 232 Unlimited number of external protocols can be added -- yes Uploads can be made unavailable to callers for downloading -- yes The SYSOP can specify: A caller's minimum security level required to: download files -- yes upload files -- yes overwrite existing files -- yes categorize files -- yes view uploaded files -- yes An upload time credit be applied to a caller's session time for time spent uploading -- yes To apply the upload time credit to the maximum time per day-- yes To automatically track the ratio of uploads/downloads for all callers -- yes for no callers -- yes for each of the 65,000 security levels -- yes To base the ratio of uploads to downloads on the number of files transferred -- yes or characters transferred -- yes To allow callers access to file downloading based on the caller's ratio of uploads to downloads -- yes To allow callers to download files only after they have been logged on a certain number of minutes in each session -- yes 2.4 The User Interface: ----------------------- The interface shown to the caller allows the SYSOP to: Substitute any letter for any command -- yes Disable commands -- yes Restrict specific commands to some security levels -- yes Only show callers the commands available to them -- yes Group commands into any sections -- yes Specify how callers can move between sections -- yes Group all commands into a single section -- yes Create whatever prompt required to request user commands -- yes Create any on-line help files -- yes Create and design all menus -- yes Make commands words (i.e. ENTER to enter a message) -- yes Make commands single letters (i.e. "E" to enter a message) -- yes Make commands a number (i.e. "1" to enter a message) -- yes Make commands "macros" (i.e. a series of valid commands) -- yes Make any item on a menu a "sub-menu" (i.e. selecting the item displays another menu) -- yes Have an unlimited number of submenus -- yes Highlight strings found in searches with colors -- yes Support colored prompts -- yes Allow the prompts to be different colors -- yes Allow menus to be ASCII, graphic, or colored/animated -- yes Provide personalized text files (help, etc.) -- yes RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 25 of 232 User "friendly" features are that the software Allows callers with unusual names (hyphenated) -- yes Allows callers with similar names (J. Joe and J. M. Joe) -- yes Allows the SYSOP to accept callers with the same names (i.e. two John Jones) and still distinguish between them by and field in the user record (e.g. city/state) -- yes Allows the prompt for the caller's first and last name to be configurable by the SYSOP -- yes Addresses the caller by the first name -- yes Thanks the caller for uploads -- yes Thanks the caller for messages -- yes Thanks the caller for calling -- yes Shows all defaults with [] (i.e. brackets) -- yes Allows callers to "see and do" (i.e. not have to back out of current section or command to do something) -- yes Allows users to choose "novice" or "expert" modes -- yes Provides short reminders of the commands in prompts -- yes Provides on-line help for any command -- yes Provide different help levels for "novice" and "experts" -- yes Allows "command stacking" -- yes Accepts unlimited type ahead from remote users -- yes Provides a fast logon (directly locates the user's record) -- yes Automatically pages the SYSOP when a specific user logs on -- yes Prevents text from scrolling off the top of a user's screen-- yes Wipes off prompt for next screen when caller continues -- yes Takes the phone off the hook (so callers get a busy signal) when the SYSOP is on locally doing maintenance -- yes Informs the caller who "pages" the SYSOP of the times that the SYSOP is normally available -- yes Automatically logs off a caller who is inactive based on a time period set by the SYSOP -- yes Allows callers to see log of others who called that shows: Name, date, and time other callers logged on -- yes City and state other callers were from -- yes The software remembers the "preferences" set by the caller for: Preferred file transfer protocol -- yes Type of displays to be shown (ASCII, graphic, colors) -- yes Lines per page (or screen) at the user's terminal -- yes Margin width when entering messages -- yes Upper case only or upper & lower case -- yes A prompt bell with each command prompt -- yes Padding end of lines with nulls (for hardcopy terminals) -- yes Sending a line feed after every line -- yes End-to-end echoing of characters (normally turned off by a caller using networks that have relay delays like PC-Pursuit) -- yes "TurboKey" - acting on first letter entered at prompt -- yes Reviewing files immediately upon logging on -- yes RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 26 of 232 2.5 SYSOP Protection: --------------------- Because a SYSOP is absolutely and personally responsible for what is communicated, the software protects the SYSOP by: Recording all caller activity by caller, date, and time -- yes Recording all communication among callers -- yes Allowing the SYSOP to preview messages between callers -- yes Allowing the SYSOP to preview files that are uploaded before they are available to other callers -- yes Automatically locking out callers who attempt to break the system -- yes Automatically denying access to callers who use names that the SYSOP deems unacceptable -- yes Allowing the SYSOP to "chat" directly on-line with a caller -- yes Preventing callers from chatting directly on-line with each other outside of the SYSOP's control -- yes Assigning each caller a specific security levels -- yes Designating the minimum security level to use each command -- yes Allowing the SYSOP to assign security levels to commands -- yes Allowing the SYSOP to assign security levels to callers -- yes Allowing the SYSOP to change any caller's security level -- yes Allowing the SYSOP to assign a security levels to files or groups of files that a caller must have in order to access them -- yes Allowing the SYSOP to require callers to know specific passwords to access files or groups of files -- yes Allowing the SYSOP to require callers to have BOTH a specific security level AND know a specific password in order to access a file or a group of files -- yes Allowing files to be protected (by requiring a password and/or a minimum security level to access) based on any combination of subdirectory, -- yes disk drive, -- yes fully qualified names, -- yes file extensions, -- yes "wildcards" -- yes Allowing "personal" files (i.e. files that only a specific caller can access -- yes Allowing each command to have a specific security level that designates the minimum security level needed to use the command -- yes Automatically paging the SYSOP when a specific caller logs on (without the caller knowing it) -- yes Instantaneously allowing the SYSOP to lock out and immediately disconnect an on-line caller -- yes Enabling the SYSOP to display the on-line caller's profile (i.e. all the information about the caller) anytime a caller is on-line without the caller being aware of it -- yes RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 27 of 232 2.6 SYSOP Functions, Features, and Support: ------------------------------------------- The software can be set to automatically drop to DOS at a specific time of day (i.e. to do system maintenance, etc.) -- yes The software can support and interface with store-and-forward electronic mail systems (i.e. FIDO, BINKLEY TERM, SEADOG) -- yes From the local keyboard's function keys, the software allows the SYSOP to: Exit to DOS -- yes Toggle on or off if callers can "page" the SYSOP -- yes Toggle the local print on and off -- yes Log on locally to the system without calling in -- yes Cause the system to immediately answer the phone -- yes Enter input from the local keyboard on the caller's behalf -- yes Grant a caller temporary SYSOP privileges -- yes Temporarily increase or decrease a caller's security level in increments of one or five -- yes Permanently change a caller's security level -- yes Temporarily change the elapsed time of the current caller's session by one or five minutes -- yes Display on the local screen what the caller sees -- yes Invite the caller to "chat" with the SYSOP -- yes Immediately lock out and log off the caller -- yes Automatically log the SYSOP on next after current caller -- yes The commands a SYSOP can execute locally or remotely are: Exit to DOS -- yes Toggle on or off if callers can "page" the SYSOP -- yes List the comments that have been left to the SYSOP -- yes List the log of the caller's activities that shows Name, date, and time a caller logged on -- yes City and state the caller was from -- yes Date and time a caller logged off -- yes If the caller was logged off due to inactivity -- yes If the caller was logged off due to carrier lost -- yes Baud rate and communications parity caller used -- yes Files downloaded and uploaded -- yes Success or failure of file transfers -- yes Protocol used for file transfers -- yes Number of characters transferred -- yes Which bulletins a caller read -- yes Which conferences a caller entered -- yes Which messages a caller read -- yes Which messages a caller left -- yes Which messages a caller killed (i.e. deleted) -- yes If the caller left a comment -- yes If the phone was answered but nobody logged on -- yes Caller was a newuser -- yes A newuser changed their name/address -- yes If caller changed password (and to what) -- yes Questionnaire answered by the caller -- yes RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 28 of 232 Restore a message that was killed (i.e. deleted) -- yes Erase the comments file -- yes Maintain the file of users by: Adding a user -- yes Listing the file of users -- yes Printing the file of users on a local printer -- yes Deleting a specific user's record -- yes Scanning every user record for a specific string -- yes Scanning every user record for a specific user -- yes Modifying a specific user's password -- yes Modifying a specific user's graphics preference -- yes Setting a specific user's security level -- yes Changing the beginning of a user's subscription -- yes A SYSOP can identify callers by: Any field in the user's record (i.e. account code) -- yes Supplying a configurable prompt for the field used to uniquely identify callers (i.e. employee number) -- yes Allow interior blanks in caller's names -- yes A SYSOP can have on-line questionnaires that All users are required to answer -- yes Only new users are required to answer -- yes Are unlimited in number -- yes Contain an unlimited number of questions within each -- yes Record all answers to a different file -- yes Automatically raise or lower a caller's security level based on the caller's answers -- yes The software supports file sharing (i.e. updating) in the networks such as: MultiLink (Version 4.0 and earlier) from the Software Link -- yes OMNINET from Corvus -- yes PC-NET from Orchid -- yes DESQview from Quarterdeck -- yes 10NET from Fox Research -- yes any environment compatible with NETBIOS from IBM -- yes In a DoubleDOS environment, the software minimizes its resource demand while waiting for work in order to free as much power for other applications that are running -- yes 2.7 System Access Management: ----------------------------- The SYSOP can specify: A maximum time per session for callers -- yes A maximum time per day for callers -- yes A different session time be allowed for each of the 65,000 different security levels -- yes A different maximum time allowed callers on the system each day based on the caller's security level -- yes A minimum baud rate for new callers to logon with -- yes A different minimum baud rate for existing callers to logon-- yes A different maximum time per session based on time of day RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 29 of 232 (hour and minute) the user logged -- yes A maximum time per day that is different from the maximum time per session -- yes To allow callers access to other applications (i.e. doors) only after they have been logged on a certain number of minutes in each session -- yes To allow all callers access to the entire system (open) -- yes To allow only pre-registered calls access to the entire system (closed) -- yes To allow automatic and instant access to the system for for new users without pre-registering them based on information pre-loaded into the system (i.e. account codes, employee numbers, etc.) and issued to callers before they access the system -- yes The software provides an optional subscription management system that: Is built-in -- yes Is automatic (i.e. requires minimum SYSOP effort) -- yes Is optional -- yes Bases the subscriptions on the date of the caller's first access to the system -- yes Subscribers are given temporary, date-limited, "trial periods" that allow them to access more features -- yes The number of days prior to a caller being warned that the subscription expires can be SYSOP-specified by -- yes Automatically warns subscribers before their sub- scriptions expire -- yes Automatically reduces the subscribers system security level upon subscription expiration -- yes 2.8 Communications: ------------------- The software will automatically answer the phone and adjust to a caller's communications settings -- yes allow the modem to adjust to the caller's communications settings while maintaining a higher data transfer rate (19200 baud) between itself and the modem to which it is attached -- yes recognize a caller who calls at: 300 baud -- yes 1200 baud -- yes 2400 baud -- yes 4800 baud -- yes 9600 baud -- yes 19200 baud -- yes recognize the MNP (automatic error correction) protocols built into the modem it is attached to -- yes recognize Hayes' pseudo LAP-B (automatic error correction) protocol if the modem it is attached Hayes is a Hayes modem with such protocol -- yes recycle if no calls are received in a specified period -- yes switch to N/8/1 for binary file transfers without disconnecting the user -- yes RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 30 of 232 The software will allow a 300 baud caller to shift to 450 baud while on-line without disconnecting -- yes The software supports modems that do not handle modem commands but which can automatically answer the phone -- yes The software handles "flow control" via: Clear-to-send (CTS) -- yes XON/XOFF -- yes The software supports attachment directly to a private branch exchange (PBX) -- yes a public data network via an X.25 PAD -- yes The software has optional, configurable modem commands to: initialize the modem's firmware -- yes initialize the modem each time the software recycles -- yes set up the modem to answer the phone on each recycle -- yes set the number of rings to answer the phone -- yes answer the phone -- yes take the phone off the hook -- yes The software can be configured to wait a specified number of seconds: after initializing the modem on recycling -- yes wait after issuing a modem command -- yes before logging off an idle caller -- yes after answering the phone for a carrier -- yes The SYSOP can set the number of rings the software answers on -- yes The software can be set to wait to issue modem commands when the phone is not ringing -- yes The software can utilize external communications drivers (for communications ports not supported by BASIC) -- yes 2.9 "Base-Line" Hardware and Software Requirements: --------------------------------------------------- RBBS-PC is designed to run on an IBM Personal Computer running IBM's Disk Operating System (DOS), communicating via an IBM Asynchronous Communications Adapter and a Hayes Smartmodem modem. For RBBS-PC CPC17- 1A, the following equipment and software is the MINIMUM and the recommended: Minimum Recommended System: IBM PC (Intel 8088 CPU) Any PC with an Intel 8088 CPU that can run IBM's PC-DOS Monitor: 80 column monochrome 80 column color monitor Asynchronous Communications Adapter: RS-232 adapter with an IBM Asynchronous communications Intel 8250 CPU adapter (serial port), RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 31 of 232 Modem: Any Hayes 1200 Smart- U.S. Robotics 9600 baud modem (or 100% Hayes Courier HST compatible!) Telephone Line: Voice grade telephone Voice grade telephone connection for modem connection for modem Modem Cable: 25 pin RS-232 modem 25 pin RS-232 modem cable (for external cable (for external modem) modem) RAM: 320K RAM available for 640K RAM available for DOS and RBBS-PC DOS and RBBS-PC Disk: one double-sided drive one high-density drive (360K) (1.2 or 1.44 MB) and one hard disk with at least 20MB Operating System: PC-DOS 2.0 PC-DOS 3.1 (or greater) The .EXE files are distributed with RBBS-PC as well as the BASIC source code so it is not necessary to have a BASIC Compiler to run RBBS-PC. However, for those who would like to compile RBBS-PC from the source code the recommended compiler is Microsoft's QuickBASIC 3.0. The MINIMUM configuration that RBBS-PC can be run in is on an IBM PC that has 320K of random access memory (RAM), one double-sided disk drive, an RS- 232 communications port with a Hayes modem and IBM's PC DOS 2.0 (or higher). To run in 320K it is necessary to recompile RBBS-PC -- see Appendix Y. As with ANY bulletin board system, the less disk space available the more file maintenance the SYSOP must do. Also if you choose to allow external file protocol transfers, an additional 192K of memory is required if you SHELL to them rather than EXIT. Beginning with RBBS-PC version CPC13-1A, RBBS-PC requires version 2.0 or above of IBM's Disk Operating System (DOS). RBBS-PC will not run under the BASIC interpreter. RBBS-PC runs under MS-DOS to the extent that the executable code generated by the IBM/Microsoft BASIC compiler is compatible with the multitude of different MS-DOS'. Do not expect RBBS-PC to run under every variant of DOS on every IBM compatible. If you have a second telephone installed specifically for RBBS-PC, ask for a second voice grade telephone line. Data lines are very expensive and are not necessary. The program requires the use of a Hayes Smartmodem (or one that is 100% Hayes compatible) in order to function properly. If your non-Hayes modem doesn't work with RBBS-PC, send RBBS-PC (source code and all) to the vendor and ask him to explain why it doesn't work (i.e. why it is "incompatible" with the Hayes Smartmodem). Callers who come in at even parity and 7 data bits, then try to change to no parity and 8 data bits to use XMODEM, may have a problem if they are using PC-TALK and a Hayes Smartmodem. Switch 1 on the caller's modem has to be down (the factory default position) or the carrier will be dropped when the communication parameters are switched. To avoid this RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 32 of 232 the PC-TALK caller will have to enter the escape code (factory setting "+++"), reset the modem parameters with Alt-P and/or Alt-F, and then return to the "connect" state with the command "ATO." Callers who wish to communicate at 450 baud have to call in at 300 baud then switch to 450 using the N)ew baud selection from the "Utilities" menu. 3. RBBS-PC's SUPPORT POLICIES ----------------------------- 3.1 RBBS-PC's Vendor Support Policy ----------------------------------- The only reason RBBS-PC is "hardware-specific" to the IBM PC and the Hayes Smartmodem is that these have pretty much set an industry standard (let's not debate the issue of whether they have also set a "technology" standard). If you follow the code in RBBS-PC closely, you will notice that a great deal of effort was expended in order not to be "hardware-dependent" on either the Hayes or the IBM PC. The purposes of RBBS-PC are outlined in section 1 of the RBBS-PC documentation. Those who contribute to RBBS-PC do so without any hope of monetary reward. In fact, great lengths are taken to assure that neither those involved with the development of RBBS-PC nor anyone who distributes RBBS-PC does so for either personal gain or to promote a specific product at the expense of other products. If the hardware you are using is not part of the "base-line" hardware and RBBS-PC doesn't work, your only recourse is to either modify RBBS-PC to meet your particular hardware's needs (that's why the source code is distributed) or contact your vendor and ask him to fix his hardware or modify RBBS-PC (via .MRG/.DOC files) to support his hardware. Since 1984 RBBS-PC became something of an "industry standard." As such several manufacturers have requested that support for their particular hardware and/or software be incorporated into RBBS-PC. These vendors have had three choices: 1. Obtain a copy of the BASIC source code by sending $8 to the Capital PC User Group's Software Exchange. The source code allows the vendor to determine what is required to be "RBBS-PC compatible." Who better knows the quirks of the manufacturer's product than the manufacturer? RBBS-PC's limited license specifically permits the distribution of ".MRG" files that would allow RBBS-PC to run with whatever idiomatic quirks a specific vendor's product exhibited. The advantage to the manufacturer is that he is in complete control and need not make the .MRG "universal" (i.e. it need only support his product). The disadvantage is that new releases of RBBS-PC come out every six to eight months and the vendor would have to review each release to make sure the new releases and his .MRG files were compatible. Of course, as with any other RBBS-PC operator, casual telephone support is available to these vendors. 2. Supply the necessary equipment or software on a loan or gift basis to be used in the testing of future releases of RBBS-PC. This RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 33 of 232 approach has been actively DISCOURAGED for three fundamental reasons. 1.) The vendor perceives he has "paid" for on-going support by the loan or donation of the product. This is not the case because RBBS-PC's development is an all-volunteer activity. As such, neither I nor any of the others involved with the development of RBBS-PC may have the time nor expertise sufficient to assure compatibility of the specific vendor's product with future releases of RBBS-PC. About all that can be done is to give the vendor our "best effort" to assure compatibility, and advise when it can not be made compatible. 2.) The particular product may not have a universal applicability to RBBS-PC users and (or) may not be of interest to those who regularly contribute to the development of RBBS-PC. Both of these conditions must exist before any vendor's product is incorporated into the RBBS-PC development cycle. 3.) The price of the loaned or donated products (usually 3 to 5 such products) in no way can even begin to compensate for the hundreds (if not thousands) of development hours required to support other than "base-line" hardware. 3. Establish an on-going institutional commitment to maintain a dialogue between the vendor's engineering group and the RBBS-PC development team along with supplying the necessary equipment or software on a loan or gift basis to be used in the testing of future releases of RBBS-PC. This approach has been actively ENCOURAGED for three different and fundamental reasons. 1.) The vendor overtly makes an institutional commitment to jointly participate in the development of RBBS-PC. The vendor has the opportunity to supplement the all-volunteer activity that is the basis for RBBS-PC development by choosing to either modify their current or future products to be compatible with RBBS-PC or to supply software that ensures compatibility with RBBS-PC. This benefits all RBBS-PC users. 2.) The particular products that fall into this category are required to have a universal applicability to RBBS-PC users (i.e. multi-tasking DOS, networking, 2400 or greater baud capability, error-free protocols, etc.). Also a regular contributor to RBBS-PC's development must be geographically located close to the vendor's development engineers to assure a timely dialogue. Further any regular contributor to RBBS- PC's development who accepts the responsibility for assuring RBBS-PC's compatibility with a particular vendor's product must be willing to do so solely on a volunteer basis over an extended period of time and in such a way as not to exclude other vendor's products. Only when all these conditions exist is any vendor's product a candidate to be incorporated into the RBBS-PC development cycle. This assures that the RBBS-PC user community has a feed-back mechanism to the vendor's product development and design teams and the vendor is assured of a matching long-term commitment from the RBBS-PC development team. RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 34 of 232 3.) The vendor recognizes that the price of the loaned or donated products (usually 3 to 5 such products) is minuscule compared with the hundreds (if not thousands) of man-hours that may be required from both the RBBS-PC development team as well as the vendor's engineers. This assures that the vendors who choose this third approach are committed to the PC user community. It is precisely this type of commitment that RBBS- PC's USERWARE concept is designed to encourage (from both users and vendors) Vendors who have chosen to make this third type of commitment to RBBS-PC and the PC user community deserve the respect and encouragement of every PC user and are (alphabetically): Ark Electronic Products, Inc. 325 W. Hibiscus Blvd. Melbourne, Florida 32901 (305) 724-5260 Corvus Systems, Inc. 2100 Corvus Drive San Jose, California 95124 (408) 559-7000 The Forbin Project (c/o John Friel III) 4945 Colfax Avenue South Minneapolis, MN 55409 Hayes Microcomputer Products, Inc. 5923 Peachtree Industrial Blvd. Norcross, Georgia 30092 (404) 449-8791 International Business Machines Corporation (Internal Zip Code 2900) P.O. Box 1328 Boca Raton, Florida 33432 (305) 998-2000 Microcom, Inc. 1400A Providence Highway Norwood, MA 02062 (617) 762-9310 Multi-Tech Systems, Inc. 82 Second Avenue, S.E. New Brighton, Minnesota 55112 (612) 631-3550 Orchid Technology 4790 Westinghouse Drive Fremont, CA 94539 (415) 490-8586 RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 35 of 232 PC-SIG 1030 E. Duane Ave Suite D Sunnyvale, CA 94086 (408) 730-9291 Prometheus Products Incorporated 4545 Cushing Parkway Fremont, CA 94538 (415) 490-2370 Quarterdeck Office Systems 150 Pico Blvd. Santa Monica, CA 90405 (213) 392-9701 Racal-Vadic 1525 McCarthy Blvd. Milpitas, California 95035 (408) 774-0810 The Software Link, Inc. 8601 Dunwoody Place Suite 336 Atlanta, GA 30338 (404) 998-0700 The Source 1616 Anderson Road McLean, Virginia 22102 (703) 734-7500 System Enhancement Associates 21 New Street Wayne, NJ 07470 (201) 473-5153 U.S. Robotics, Inc. Skokie, Illinois 60076 (312) 982-5010 Users who feel that they have benefited or who appreciate such commitment to the user community should write or call the above vendors and tell them so, especially if such a commitment influenced the purchase of their products. Similarly, if any user feels that other vendor should make a similar commitment to RBBS-PC and the user community, write to that vendor and send a copy of your letter to the following address: D. Thomas Mack 39 Cranbury Drive Trumbull, Conneticut 06611 Section 21 describes the RBBS-PC standard interface for protocol drivers. All vendors of proprietary protocols who would like to have them added to future releases of RBBS-PC need do is simply conform to this interface. RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 36 of 232 3.2 RBBS-PC's User Support Policy --------------------------------- RBBS-PC is an all-volunteer effort on my part. Professionally I am not a programmer (as anyone who has looked at the source code can testify) nor an "expert/guru" on personal computers. Since I am not independently wealthy, I have a full time job (unrelated to PC's). As with most other folks, I'm also busy raising a family. What time I can spare from these other activities I am glad to donate to answer questions about RBBS-PC as I believe (somewhat fanatically) in the Userware concept. However, if you have questions regarding something other than the "base- line" hardware and software requirements outlined in section 2.9, DON'T CALL ME. I probably can't help you anyway and even if I do venture some advice it will probably be wrong. One of the axioms of the "Userware" concept is that every user should be able to help themselves -- that's why there are more than 226 pages of documentation and the source code is freely distributed (under a limited license and copyrighted). The only calls that I truly appreciate are those that reveal BOTH a problem and a solution. These I am more than happy to share with anyone and are included in RBBS-PC (either the documentation, the software, or both) as rapidly as possible. Of course, if you encounter a problem and 1. read and re-read the documentation, 2. spend days and days attempting to isolate it, 3. called other SYSOPs and asked their help, 4. looked up any error messages you encountered (they are in the BASIC manual that comes with your IBM PC's DOS), 5. know what version of RBBS-PC that you are running, 6. know what version of CONFIG that you are running, 7. eliminated all other software from your environment, and still can not get RBBS-PC to work, I am most happy to lend whatever telephone advice I can. RBBS-PC'S Technical Support phone number is (203) 268-9656. If you get the answering machine please leave your name and phone number where you can be reached in the evenings. (Do not leave Data numbers, Voice only please!) Someone will return your call (COLLECT) to try and help you with your problem. In this regard, it may help to remember that there are only two types of problems -- MY problems (which are the ones that I can solve) and OTHER PEOPLE's problems (which are the ones that I can't solve). 4. HOW TO GET A COPY OF RBBS-PC SENT TO YOU -------------------------------------------- RBBS-PC can be obtained by sending a check for $8 to the Capital PC Software Exchange P.O. Box 6128 Silver Spring MD 20906. RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 37 of 232 RBBS-PC is distributed on two double-sided, 9-sector, diskettes. Allow 3 to 4 weeks for delivery -- remember this is an all-volunteer effort. Be sure to specify RBBS-PC CPC17-1A on "diskette # 18". If you would like the RBBS-PC source code and some utilities that other SYSOPs have found useful, send a second $8 with your order and ask for "diskette #18S." Version CPC17-1A of RBBS-PC's .EXE file is distributed after having been compiled with QuickBASIC Version 3.00 compiler that had the DTR patch described in Appendix T applied to it. The exigencies of RBBS-PC software releases may mean that diskette 18 contains an earlier version of RBBS-PC than CPC17-1A (either you bought diskette 18 sometime ago or there has been not enough time for diskette 18 to be updated to this most current version). Not to fear! Your $8 has not been wasted. At least three bulletin boards keep the most current copies of RBBS-PC for downloading. They are: (203) 268-5315 --+ +---- East Coast (Trumbull, Conneticut), (203) 268-0129 --+ (703) 978-6360 ------- East Coast (Fairfax, Virginia), (415) 689-2090 ------- West Coast (Concord, California). For those interested, PostScript output files of RBBS-PC's documentation are available from the NICBUL RBBS-PC system, run by the Nicolet Instrument Corp., by downloading the files named RBDOCPS1.ARC through RBDOCPS7.ARC. The seven ARC files are needed because the formatted documentation would be too large for a single file. The SYSOP is Michael L. Brown and the bulletin board number is (608) 273-5037. If you want it in "hard copy" form, send a check for $5.00 to cover book rate shipping and printing costs to: Michael L. Brown Nicolet Instrument Corporation 5225-2 Verona Road P.O. Box 4288 Madison, WI 53711-0288 5. FILES RBBS-PC USES --------------------- There are essentially two types of files that RBBS-PC uses -- "system" and "text" files. "System" files are defined as random files that RBBS-PC reads and writes to. "Text" files are defined as files that RBBS-PC primarily reads from. Text files can be edited externally to RBBS-PC with most text editors that can handle ASCII files. Either type of file can be "static" or "variable" in length. By "static" it is meant that these files have a pre-defined length beyond which RBBS-PC does not extend them. Similarly, "variable" length files are defined as those files whose length is dynamically increased by RBBS-PC. In a multiple RBBS-PC environment only the "static" length files can be shared SAFELY among the various RBBS- PC's. The following table summarizes this using the default file names: RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 38 of 232 "Static" Length Files "Variable" Length Files ----- /|\ MESSAGES CALLERS ARCWORKx.DEF | USERS COMMENTS NODExWRK System MESSAGES.BAK upload disk RBBSxF1.DEF Files USERS.BAK DKxxxx.ARC DORINFOx.DEF | RBBSxPC.DEF upload disk \|/ 99.DIR (upload directory) ----- The following "text files" are "static" in length and can be shared safely: ----- NEWUSER RBBS-CDR.DEF /|\ MENU0 --> MENUA LGx.DEF | BULLET, BULLET1 --> BULLETn AUTOPAGE.DEF | DIR.DIR, aa.DIR --> bb.DIR CONFMAIL.DEF | CDR.CDR, aa.CDR --> bb.CDR RBBS-CDR.DEF Text FILESEC PROTO.DEF Files CONFENCE RBBS-REG.DEF | xxxx.PUI PRELOG.DEF | PASSWRDS EPILOG.DEF | xx.HLP PRIVATE.DEF | HELPxx AUTOPAGE.DEF \|/ TRASHCAN RBBSxTM.DEF ----- WELCOME In a CORVUS network environment any of the "static" length files can be shared on a common volume and ALL of the "variable" length files must be segregated on volumes unique to each copy of RBBS-PC. RBBS-PC issues the NAME function of BASIC in order to determine if a file exists. Because of this, all the volumes accessed by any RBBS-PC in a CORVUS network must be designated "read/write." Therefore, you must be very careful when running CONFIG.BAS. CONFIG creates the definition file (RBBSxPC.DEF) for each copy of RBBS-PC. In a MultiLink (from the Software Link, Inc.) environment and in Orchid's PC-NET environment the vendors claim that not only all the "static" length files can be shared on a common volume but also some of the "variable" length files can be shared. However, if you want to be as conservative as possible, run RBBS-PC in ALL environments as if it where running in a CORVUS network environment. However, if you rely on the vendors claims, in either a MultiLink or PC-NET environment, when running CONFIG.BAS which creates the definition file (RBBSxPC.DEF) for each copy of RBBS-PC, you must be careful to put at least the CALLERS file on an unshared volume. 5.1 RBBS-PC System Files ------------------------- As shown above, "system" files are both static and variable in length. The system files used by RBBS-PC are: MESSAGES - This file is a random file that contains the message text for the RBBS-PC system. The first record in the file contains the RBBS-PC "checkpoint" record. The records immediately following this first record are the RBBS-PC "node" records. The rest of the RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 39 of 232 file consists of message header records which are followed by the message text for that header. Appendix A describes the fields and their uses within the various type of records of the messages file. RBBS-PC expects the MESSAGES file to exist and to have been created by the CONFIG utility. If CONFIG does not find the MESSAGES file or it finds one in pre-CPC12-3A format, it will create it and initialize it to the size the SYSOP specifies. Because of the fixed length records in this file, it should not be created or edited outside CONFIG. When the SYSOP "packs" the message file using CONFIG, the file MESSAGES.BAK is created to hold the old messages in case the "pack" is unsuccessful (i.e. not enough space to duplicate the message file). If the disk fills up during the pack function RBBS-PC will recover the message file using MESSAGES.BAK. When the messages file is successfully packed, the pre-packed messages file is renamed MESSAGES.OLD and the temporary file MESSAGES.BAK is renamed MESSAGES. The MESSAGES file should only be "packed" in a multiple RBBS-PC environment when there are no RBBS-PCs active. The MESSAGES file can be shared among multiple RBBS-PCs. USERS - The USERS file is a random access file that has a record for each user who used the system. The record contains a profile for each user who has logged onto RBBS-PC. Appendix A describes the format of the records within the USERS file. The records are 128 bytes in length and are automatically maintained by RBBS-PC. The SYSOP can do some limited editing using SYSOP function 5. To initialize the system simply ERASE this file. RBBS-PC expects the USERS file to exist. If the utility CONFIG does not find the file on the system it will create it to the size specified by the SYSOP. The USERS file should not be created or edited outside CONFIG. When the SYSOP "packs" the user file using CONFIG, the file USERS.BAK is created to hold the old users in case the "pack" is unsuccessful (i.e. not enough space to duplicate the users file). If the disk fills up during the pack function RBBS- PC will recover the USERS file with USERS.BAK. When the users file is successfully packed, the pre-packed users file is renamed USERS.OLD and the temporary file USERS.BAK is renamed USERS. The USERS file should only be "packed" in a multiple RBBS-PC environment when there are no RBBS-PC's active. The USERS file can be shared among multiple RBBS-PC's. CALLERS - This file is a random file that contains a log of all callers as they log on to the system along with callers city and state, the date and the time. The names are added to the end of the file as well as are the names of the files uploaded/downloaded by the caller. If the file is not found RBBS-PC will create a new one. The file should be ERASED to clear the log. The CALLERS file cannot be shared among multiple RBBS-PC's. COMMENTS - This file is a sequential file that contains any comments that have been left by users for the SYSOP. The file can be scanned by a SYSOP function or it can be TYPEd or edited outside the RBBS-PC system. A SYSOP function is available to delete this file, or it can be emptied outside of DOS. The file will be created by RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 40 of 232 RBBS-PC if it is not found. The COMMENTS file cannot be shared among multiple RBBS-PC's using CORVUS' "OMNINET". This file can be shared using MultiLink or Orchid. 99.DIR - The default file name on the upload disk that is to have the name, file size, date, and description appended to it of files that have been uploaded. The 99.DIR file cannot be shared among multiple RBBS-PC's using CORVUS's "OMNINET", but can be shared using MultiLink or Orchid. RBBS-PC.DEF - This is an ASCII text file created as output by the CONFIG program. It contains the configuration parameters for the RBBS-PC. It is read by RBBS-PC to determine the configuration settings tailored to your RBBS-PC. In a multiple RBBS-PC environment the definition file for each RBBS-PC is named RBBSxPC.DEF where "x" is a number 1 through 9 , 0 (for the tenth copy), and A through Z (for the eleventh through 36th copy) corresponding to which copy RBBS-PC it describes. In a single RBBS-PC environment the name will be RBBS-PC.DEF. RBBS-PC displays on line 25 the status of those files which must be locked in a network environment. The lock status of the message file is displayed in positions 68 & 69. The lock status of the user file is displayed in positions 71 & 72. The lock block status is displayed in positions 74 & 75 and comments/uploads share positions 77 & 78. The letter "U" in the first position shows that the file is currently "UNLOCKED". The letter "L" in the first position indicates that the file is "LOCKED". ARCWORKx.DEF - This file is created as output by the ARC view command and contains the contents of the ARC file being inquired against. QMXFER.ERR - This file is created as output by QMXFER.COM to notify RBBS- PC of the results of an external file protocol transfer. DKxxxx.ARC - This file is created as output by the Library Sub-System archive program. This work file is deleted each time RBBS-PC recycles. DORINFOx.DEF - This file is created by RBBS-PC when a caller exits to a DOOR. It contains information about the caller needed by a "DOOR". It consists of an twelve record file that contains the following information: 1. The name of the RBBS-PC system 2. The SYSOP's first name 3. The SYSOP's last name 4. The communications port being used 5. The baud rate and parity the caller logged on at and the baud rate that RBBS-PC is connected to the modem at 6. The network type (if any) RBBS-PC is running in 7. The caller's first name 8. The caller's last name 9. The city and state the caller is from 10. The caller's graphics preferences 11. The caller's security level RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 41 of 232 12. The caller's time remaining in the current session NODExWRK -- This file is created by RBBS-PC when a caller exits to an external protocol to do "batch" downloads. It contains a list of fully qualified file names to be downloaded. 5.2 RBBS-PC Text Files ----------------------- Similarly, the RBBS-PC "text" files are both static and variable in length. The "text" files used by RBBS-PC are: BULLET - This is a text menu file that is printed following the WELCOME file when a user first enters the system. It must be present if "CONFIG Utility parameter 43" is greater than 1. It can also be called from the main menu with the <B>ulletins command. BULLET1 --> n -- There can be 1 to 99 "bulletins". RBBS-PC will check for the existence of a file whose name consists of the prefix given by parameter 44 of CONFIG.BAS appended with the bulletin number and using parameter 41 of CONFIG.BAS to determine the drive to find the bulletin on. Users can elect to have displayed two different types of "graphics" files for such standard RBBS-PC system files as HELPxx, BULLET, MENU's, etc. In order for a user to see either of these two different types of "graphics" files, the following must have occurred: logged on N/8/1, requested graphics (either full ASCII or "color/music"), and the file must exist and the filename end in either: "G" for files containing the graphic ASCII characters whose values are in the range 129 to 256, or "C" for files containing combinations of the full 256 characters that the caller's communication software can interpret and translate into colors and music (e.g. PCTK666, QMODEM, and EXECPCT). RBBS-PC will check to see if a "graphics" files exists by appending a "G" or "C" to the file name. If such a file can't be found, RBBS-PC will check to see if a non-graphics file exists (i.e. one without the "G"). RBBS-PC will display the first file it finds or a message that the file can not be found. DIR.DIR, aa.DIR --> nn.DIR -- At least one DIR.DIR file has to be present on one of the drives available for downloading. Alternative directories, aa.DIR --> nn.DIR (see section 13), should be meaningful and should be reflected in the DIR file. CDR.CDR, aa.CDR --> nn.CDR -- At least one CDR.CDR file has to be present on one of the drives available for downloading if the Library Sub-System support has been activated. Alternative directories, aa.CDR --> nn.CDR, should be meaningful and should be reflected in the CDR.CDR file. RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 42 of 232 FILESEC - is more fully described in section 17.4 on security. HELP -- There is a help file for each command which has the format xy.HLP, where x is the first letter of the section (M,F,U) and y is the command letter. There are also the following special help files: MAIN.HLP -text file that is printed when <H>elp is requested on the main function prompt. It contains command information. HELP03 -text file that describes the message protection options when <?> is entered after the message <E>nter command is executed at the main message menu. HELP04 -text file that describes the message entry subfunctions when <?> is entered at the subfunction prompt. FILE.HLP -text file that is printed when <H>elp is entered in the files subsystem function prompt. UTIL.HLP - text file printed when <H>elp is requested in the utility subsystem function prompt. HELP09 -text file printed when <H>elp is requested for type of graphics a user wants (none, ASCII, color/music). LIBR.HLP - text file that is printed when <H>elp is entered in the library subsystem function.prompt. SMARTTXT.HLP - text file that illustrates the use of embedded commands within any text file displayed by RBBS-PC that causes the text to appear personalized to the caller. See section 8.9 for a fuller description of this RBBS-PC feature. UPCAT.HLP -- This is the file that is used to help user's categorized their up-uploads. SECVIO.HLP -- If this file is present, it is shown to the caller each time a security violation occurs. MENU0->A -- contain the local SYSOP menu and menu of various commands for the subsystems. It is recommended that these be placed on an electronic disk drive (i.e. RAM) rather than on a floppy or hard drive. NEWUSER - This is a text file that is displayed for new users just before registration occurs. PASSWRDS - is more fully described in section 17.3 on security. PRELOG - A text file displayed to callers prior to asking for their first/last name and password. RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 43 of 232 RBBS-CDR.DEF - is a text file that contains the disk numbers, paths and disk titles of disks available to the Library subsystem. The format of the file is described in section 13.6. The RBBS-CDR.DEF (and matching FMS directory) file can be downloaded from Jon Martins' system. It is not distributed with RBBS-PC because of it's size (500K). TRASHCAN - is a text file that contains names that the SYSOP finds objectionable and does not want used as either a users first or last name. RBBS-PC uses this file, if it exists, to deny access to anyone using one of these names for either their first or last name. WELCOME - is a text file that a user first sees upon logging onto the system. It must be present, and it should be modified to identify your system. Similarly each "conference" can have a "welcome" file by having a file whose last character ended in a "w" (i.e. conference "RBBS" would have a message file named RBBSM.DEF and a user file named RBBSU.DEF if it where a "private" conference and a welcome file named RBBSW.DEF). CONFENCE - A text file displayed to users who issue the J)oin function from the main menu. It can be created by any text editor that can create an ASCII file and should contain a list of the available conferences. LGx.DEF - This is the file displayed to users based on security level when the caller logs on. The "x" defines the security level of the users who would see this file. A SYSOP can "lock out" users (i.e. give them a security level below the minimum to logon on) for various reasons. This allows the SYSOP to provide an explanation for callers whose security level falls below the minimum to log on. It can also be used to provide a "personalized" welcome to users who have a specific security level. Callers see the LGx.DEF file corresponding to their assigned security levels. Some examples are: Security File Text that might be included in the file Level Name 9 LG9.DEF "Hi, nice to have a another SYSOP call in." 6 LG6.DEF "Registered users are the most appreciated." 4 LG4.DEF "Too many security violations." -1 LG-1.DEF "You behavior has been inappropriate." -99 LG-99.DEF "You have never uploaded anything." RBBSxF1.DEF -- This is the file dynamically created when the local SYSOP wants to drop to DOS. EPILOG.DEF -- This is the questionnaire that is shown to users who log off. It can be either an extensive "poll" (which frequent users would find tedious) or a simple thank you. PRIVATE.DEF -- This file contains the information used for "personal downloading", described in section 13.7. RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 44 of 232 RBBS-REG.DEF -- This is the questionnaire that is asked of all new users who log on. It is only seen by new users and can be as extensive as you may like or you can have none at all. MAIN.PUI -- This is the programmable user interface file that allows the SYSOP to structure the RBBS-PC commands as desired. CONFMAIL.DEF -- This is a text file setup by the SYSOP to notify callers of the mail they have waiting in specific (or all) conferences. See section 18.1 for a more comprehensive description of this feature. AUTOPAGE.DEF -- This is a text file setup by the SYSOP that informs RBBS-PC of which caller, callers, or group of callers that the system should automatically "page" the SYSOP as soon as they log on. See section 8.11 for a more comprehensive description of this feature. 6. INSTALLING RBBS-PC FOR THE FIRST TIME ----------------------------------------- RBBS-PC, unlike simpler applications such as games and utilities, is a complex application that requires someone who wishes to set up RBBS-PC to already be familiar with modems and PC communications. This section is intended to provide a step-by-step approach to setting up RBBS-PC for the first time. Follow the steps thoughtfully! Do not proceed to subsequent steps until you understand all the previous steps. However, for those who are NOT familiar with electronic bulletin board systems in general, a much better introduction to installing RBBS-PC is contained in the book "Electronic Bulletin Board Starter Kit" by Charles Bowen and David Peyton, published by Bantam Books. The book does in 436 pages what the next few pages attempt to do. It is a superb guide for someone who has never setup a bulletin board system and/or is not knowledgeable about PC or asynchronous communications. The book comes complete with an extensive index as well as a copy of RBBS-PC CPC Version 15-1C and, of course, the associated source code. Since all versions of RBBS-PC are upward compatible, this book serves equally well as a guide for the uninitiated to all subsequent versions of RBBS-PC. This book guides the uninitiated potential SYSOP in easy stages from unwrapping the two diskettes that are included with the book to operating the more advance features of RBBS-PC. The book was published by Bantam Books in August of 1988, ISBN 0-553-34552-4, and can be found in most technical book and computer stores. It addresses the topic of installing an electronic bulletin board system in a far better way than this "Technical Reference Guide" could (or would). Because RBBS-PC attempts to provide SYSOPs the maximum flexibility, it is perfectly possible for those setting RBBS-PC up for the first time to shoot themselves in the foot. Be patient with yourself. Remember that things worth achieving usually are not obtainable without effort. Because of the prevalence of hard disk usage these days, the following assumptions about the hardware to be used to set up RBBS-PC has been made: RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 45 of 232 1. IBM PC or XT with a hard disk (previously formatted!) 2. Minimum RAM of 320k (only if recompiled -- see Appendix Y) 3. Hayes external modem 4. Dedicated 'voice grade' phone line SOFTWARE REQUIRED 1. IBM PC-DOS 2.0 or higher 2. RBBS-PC.EXE - the main program 3. CONFIG.EXE - the setup program 4. RBBSDOCx.DOC - the documentation files 5. ALL of the RBBS-PC text files: MENU1 - MENU5, HELPxx, *.HLP, WELCOME, DIR.DIR, xxxxxxxx.DIR, PRELOG, BULLET, BULLETxx 6. A text editor (PE2, WS non-doc, EDLIN, etc.) to create other useful/needed text files. Your editor MUST be capable of saving spaces (hex 20's) as characters and not substitute tab characters for strings of spaces. Those mentioned above ARE. 7. WATCHDGx.COM - an external carrier monitor program where x =COMx and which is available from most RBBS-PC systems. 1. [ ] PRINT A COPY OF THE DOCUMENTATION! 2. [ ] Have dinner or take a nap while the previous step executes. 3. [ ] Create a sub-directory in which RBBS-PC is to reside. MKDIR \RBBS. 4. [ ] Change current directory to the newly created directory CHDIR \RBBS. 5. [ ] Create a sub-directory called NEW for your uploads. 6. [ ] Create any other sub-directories you desire to hold downloads MKDIR TURBO MKDIR PATCHES MKDIR UTILS etc. as sub-directories of C:\RBBS The following is a suggested 'layout' of the sub-directories and files which comprise RBBS-PC. C:\ COMMAND.COM \DOS \RBBS RBBS.BAT RBBS-PC.EXE CONFIG.EXE WATCHDGx.COM MESSAGES USERS MENU1->MENU5 MENUA HELPxx *.HLP WELCOME PRELOG (OPTIONAL) BULLET BULLET1 (HOWEVER MANY) FILESEC PRIVATE.DEF (OPTIONAL) RBBS-CDR.DEF (OPTIONAL) RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 46 of 232 LGx.DEF (OPTIONAL) AUTOPAGE.DEF (OPTIONAL) CONFMAIL.DEF (OPTIONAL) PROTO.DEF (OPTIONAL) PASSWRDS TRASHCAN CALLERS (WRITTEN BY RBBS-PC) COMMENTS (IF NOT USING COMMENTS AS MESSAGES WILL BE CREATED BY RBBS-PC) \RBBS\NEW UPLOADS.DIR (Whatever your users upload will go here) \RBBS\DIR DIR.DIR TURBO.DIR UTILS.DIR CDR.CDR (OPTIONAL FOR LIBRARY) 100.CDR (OPTIONAL FOR LIBRARY) 101.CDR (OPTIONAL FOR LIBRARY) \RBBS\TURBO (Whatever your users can download must be put here) \RBBS\PATCHES (Or here!) \RBBS\UTILS (Or here!) 7. [ ] Copy RBBS-PC.EXE to the current directory (C:\RBBS should be). 8. [ ] Copy CONFIG.EXE to the current directory. 9. [ ] Copy all MENU and HELP files to the current directory. 10. [ ] Create a text file which will serve as your bulletins menu (default = BULLET) using your text editor. Normally, it is desirable for this to be a single 23-line page or shorter. This is to serve as a 'menu' for the user to select bulletins for reading by choosing a number (1-99). Each bulletin file you create will be named BULLETxx where xx = the number on this menu file. The following illustrates what you might create: +-------------------------------------------------+ | Bulletin Menu | |-------------------------------------------------| | # | UPDATED | SUBJECT | |-------------------------------------------------| | 1 | 01/01/80 | TOPIC OF BULLETIN #1 (BULLET1) | | 2 | 01/01/80 | TOPIC OF BULLETIN #2 (BULLET2) | | 3 | 01/01/80 | TOPIC OF BULLETIN #3 (BULLET3) | +-------------------------------------------------+ 11. [ ] Create a text file for each bulletin that are going to be available BULLET1 BULLET2 ... etc. making certain that the contents of each corresponds to the indication in the bulletin menu file. 12. [ ] To support all of the graphics options of RBBS-PC you will need a separate BULLET file (BULLETG for IBM-ASCII and BULLETC for ANSI graphics). This naming convention (suffix of G or C) applies also to the menus and the directory files. If disk space is, or is anticipated to be, a problem use of only one set of menus. Graphics or color menus and bulletins are entirely optional and RBBS-PC will run fine without them. 13. [ ] Create a text file named PRELOG. Although this file is truly an an option, it is a good place for announcements which you want all callers to see. If your system restricts new users to 1200 baud or higher it is also a good place to let 300 baud callers know why RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 47 of 232 they cannot log on. 14. [ ] Create a text file named WELCOME (WELCOMEG, WELCOMEC, if desired) which can contain anything you'd like to express to your callers in the way of a greeting or other info. Many SYSOPs use this file to display their 'logo' and a brief description of the equipment they are using. 15. [ ] Now we come to the text files for the RBBS-PC file subsystem. At this point we will use the "multiple directory" format described in section 13 rather than the "single directory" format. These are the most hassle, both to create initially and to maintain. The list(s) of files are called "directories" in the documentation and should NOT be confused with DOS "subdirectories." These text files require a very specific format (see section 13.4) because RBBS-PC searches for information based on the fields being pre-determined lengths. 16. [ ] You will want a ".DIR" file to correspond to each of the DOS sub- directories available to your users for downloading. 17. [ ] Create a text file named DIR.DIR which contains a list of the available .DIR filenames (minus the extension) and some brief description of how the user may view these lists (i.e. L;XYZ or L;123). Now for some suggestions: 1) Place all your .DIR files in the same subdirectory. 2) If you don't want your upload directory seen, do NOT place it in with the other .DIR files. 18. [ ] Create a text file named FILESEC which is one of the most sig- nificant of the SYSOP generated files since it gives you total control of which files & sub-directories are available to you or your users for downloading. Files may additionally be protected from downloading by password(s) which RBBS-PC will require of the user if the file is requested. The format of this file is VERY specific as are the other security related files you will create. See section 16.4 for a description of the format of this file. 19. [ ] Create yet another text file named TRASHCAN which is checked by RBBS-PC when a newuser logs on, it will contain a list of the user names which you will not permit on your system. These might include sexually oriented or derogatory terms, computer jargon, common abbreviations, etc. See section 11.5 for a more detailed description of the format of this file. 20. [ ] Create a text file named PASSWRDS from which you may control the the logon duration of various user security levels and/or permit extending the current logon of a user through knowledge of specific passwords. Again, the format of this file is critical to its functionality. See section 16.3 for a more detailed description of the format of this file. 21. [ ] There is one more text file which you may wish to utilize. Named NEWUSER it is shown only to those persons signing on to your system for the first time. It can contain anything which you want a newuser to know about the system (ground rules, conferences, etc.). It is displayed immediately prior to the caller being asked to C)hange his logon data, D)isconnect, or R)egister on the system. 22. [ ] Create a batch file to automatically bring up RBBS-PC. Typically, this would be invoked from the AUTOEXEC.BAT file on a PC that was primarily dedicated to running RBBS-PC. See section 14 for a more detailed description of a suggested RBBS.BAT file. RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 48 of 232 23. [ ] Now with documentation in hand type CONFIG and press Enter. After a welcoming screen is displayed you will be asked if you will be running multiple nodes - for this discussion it is assumed that you have only one phone line. So type NO and press the Enter key. In a few seconds you will see the main configuration menu. You may now choose to have CONFIG guide you through the critical parameters (i.e. those that typically are unique to each RBBS-PC) or press the F1 key to access the first 'page' of the setup options. CAREFULLY answer each of the questions regarding SYSOP names, etc. If you are unsure of how to respond - refer to section 11 of the documentation. 24. [ ] Check that your modem's configuration switches have been set to the positions indicated in the docs (for Hayes 1200 external UUDDDUUD) or to the corresponding functions as listed in the documentation for your "Hayes-compatible" modem. This step can be tricky if your modem is not among those detailed in the documentation - even with the modem manual in hand. But you knew this when you saved all that money by purchasing a non-Hayes modem. 25. [ ] Press the 'End' key, respond 'YES' at the prompt and press Enter. This creates a file named RBBS-PC.DEF in the current directory. During the execution of CONFIG.EXE it will have also created two additional files (one for the user file and one for the message file) using the names you specified, or USERS and MESSAGES if you accepted the defaults. 26. [ ] Turn on your modem if external. 27. [ ] Look at your CONFIG.SYS and AUTOEXEC.BAT files and eliminate any terminate and stay resident software. 28. [ ] Make sure you are running with IBM's (not Microsoft's) PC DOS. 29. [ ] Type RBBS and press Enter. You're on your way as a SYSOP! 7. THE MOST COMMON PROBLEMS ENCOUNTERED WHEN INSTALLING RBBS-PC ----------------------------------------------------------------- IT CONTINUALLY RECYCLES! This can have several causes. RBBS-PC requires that a modem be attached to your communications port. Therefore: 1.) check what communication port is being used. 2.) verify that the communications port exists. 3.) verify that your modem is attached to it. 4.) verify that your modem is powered up. 5.) verify that your modem is configured properly. 6.) verify that CONFIG is configured for your modem. 7.) verify that the modem cable supports all ten signals required by RBBS-PC (see Appendix S). 8.) verify that DTR is set to "normal" rather than always "on" (i.e. true). 9.) verify that each DOS subdirectory referred to in CONFIG exists. 10.) verify that RBBS-PC run properly when CONFIGured for COM0 (i.e. a local workstation). If, after all of the above has been attempted, the problem still persists, try deleting your MESSAGES and USERS files and re-run CONFIG to create new ones. RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 49 of 232 Finally, having exhausted all the above remedies, the system continues to continually re-cycle, you may have an incompatible "clone" PC, incompatible DOS, incompatible modem, and/or a bad copy of RBBS-PC.EXE. IT WON'T ANSWER THE PHONE! This also can be caused by one of the following things: 1.) Phone line is not plugged into the modem. 2.) Modem is not powered on. 3.) Modem is not connected to the communications port that RBBS-PC was told to use. 4.) Your modem is not "Hayes compatible" enough to handle the modem commands described in section 12. 5.) Your modem cable does not have PIN 22 connected. RBBS-PC does not require PIN 22 to be hooked up on the RS-232 cable (that's the cable which runs between the modem and the computer) if you specify in CONFIG that RBBS-PC is to answer the phone on zero rings (and that it is not a RING-BACK system). In this setting RBBS- PC will initialize the modem so that the MODEM automatically answers the phone. RBBS-PC's default is that RBBS-PC depends on either PIN 22 (i.e. "ring indicator") or the modem sending the characters "RING" to know when the phone is ringing. This is because RBBS-PC, and NOT the modem, answers the phone by issuing the ATS1? command to determine what ring has occurred and then the ATA command to tell the modem to answer the phone (see section 12). If you modem does not send the characters "RING" each time the phone rings, then you will need a cable with PIN 22 connected. Some computers (i.e. the PCjr's external RS-232 interface) and some modem cables don't have a "ring-indicator" signal. PIN 22 is the ring indicator coming from the modem going to the computer. Just because you bought an RS-232 cable, don't assume that it has PIN 22 connected. The $55 12-pin RS-232 cable sold by many computer stores often may not have PIN 22 connected. For about $18 in parts from Radio Shack you can put together your own RS-232 cable with all the pins connected. A friend of mine paid $14.88 (including postage) for a RS-232 cable with all the pins connected by ordering part number CDB25P-4-S from Jameco Electronics. Jameco Electronics' telephone number is (415) 592-8097. There have been numerous revisions of the ROM in the Hayes modems. If all else fails, you might try adjusting the number of rings that RBBS-PC is to wait until it answers the phone (CONFIG parameter 204). If it won't answer on one ring, set it to 0. If it won't answer on zero rings, set it to one. IT LOCKS UP MY SYSTEM! Actually this is probably caused by one of the following things: 1.) The .EXE file generated by the BASIC compiler is incompatible with either the DOS that you are running (i.e. it isn't IBM's DOS) or the other software you load into the system prior to running RBBS- PC via CONFIG.SYS or your AUTOEXEC.BAT file. 2.) You indicated in CONFIG that you were running in one of the supported networks (i.e. CORVUS, MultiLink, Orchid, etc.) but you RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 50 of 232 aren't. 3.) You are running on a Compaq Deskpro (or using an add-on board that uses the unused IBM DOS interrupt X'7F') and should have used CONFIG parameter 29 to indicate you are using a Compaq PC. 4.) You are using an internal modem that doesn't have the same switch settings as the Hayes 1200 and/or your modem needs to have the result codes turned off when RBBS-PC re-cycles. Set the modem initialization string to "ATQ1E1F1M1X0H0". 8. PLANNING YOUR USER INTERFACE --------------------------------- RBBS-PC provides each SYSOP the maximum control over what is presented to callers. There are three areas of control: 1. The menus presented to novice callers. 2. What is included in the prompt all users get. 3. What symbol invokes a particular function. 8.1 Menus Shown to Callers -------------------------- The menus in RBBS-PC are external text files that are presented to novice users. RBBS-PC simply displays what is in these files to the callers. Therefore, SYSOPs are free to change the text in these files to whatever they desire. Simply edit the files. However, be sure to use an editor that produces only ASCII text files with no special embedded characters. Most word processing editors are not suitable because they insert special symbols in the file meaningful only to it. WordStar, in non-document mode, is fine, as is the Personal Editor when files are saved with no tabs, and the Program Editor. Most editors used for creating computer programs are suitable. RBBS-PC supports three types of files, which the caller can select using his graphics preference. A file with no graphics has only typable text. ASCII graphics means that all 255 ASCII values display on the caller's screen using the IBM PC display conventions. This allows support for many symbols, such as straight lines, a heart, and many others. Using these conventions, many fancy graphic displays are possible. Last, a use can request color graphics, which means that the caller's monitor supports not only the IBM display conventions but supports ANSI commands for controlling the monitor, which include such things as color as well as special modes like blinking. Using ANSI commands, it is possible to fully control the caller's monitor. One can go so far as to create animated pictures. Menu files are known by their names. The format is XXXXXXXY, where XXXXXXX is the base file name and Y is a one-character addition. Y is nothing for no graphics, G for ASCII graphics, and C for color graphics. RBBS-PC will look for a file based on the users graphic preference and display the graphics version if it exists. Otherwise, the non-graphics file is used. Graphics files have more characters in them and therefore take longer to transmit. Creating them is not easy. However, there are special ANSI and graphics editors which make creating such files much easier. RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 51 of 232 8.2 Subsystem Prompts Shown to Callers -------------------------------------- RBBS-PC has several configuration options which allow each SYSOP to select the prompts that are presented to callers. They are: 1. Whether the section name is shown. 2. Whether the letters of the available commands are shown. The commands in RBBS-PC are divided into four sections: MAIN, FILE, UTILITY and LIBRARY. Each has a set of commands in them and there are commands to move between sections. If the SYSOP elects for the section name to be shown, the command line will read "<section> command", otherwise "Your command". The default is to show the section. RBBS-PC normally prompts a caller with the commands available in each section that the caller has sufficient security to invoke. Each command is a single letter and is shown separated from the others by a comma. These command letters can either be suppressed or not. By leaving them on a SYSOP provides each caller with a terse but helpful reminder of what commands are available to them. 8.3 Commands Available to Callers --------------------------------- All primary commands in RBBS-PC are invoked by single letter commands. An attempt is made to associate the command with the first letter in a word which describes the function, so that the command letter appears to be a short abbreviation for the longer word. The command to invoke reading messages is R. The default symbols that would be shown in the command line for each section are: section|? @ A B C D E F G H I J K L M N O P Q R S T U V W X Y 1 2 3 4 5 6 7 -------|------------------------------------------------------------------- MAIN |? @ A B C D E F H I J K O P Q R S T V W X 1 2 3 4 5 6 7 | FILE |? D G H L N P Q S U V X | UTILITY|? B C E F G H L M P Q R S T U X | LIBRARY|? A C D G H L Q S V X | GLOBAL |? H Q X Four commands, ? H Q and X, have the same meaning in every section and are known as "global." The other commands all have unique function specific for the section within which they are invoked. For example, S in the main section stands for S)can messages, but S)ubstring search in files & Library, and S)tatistics on the board and session in utilities. Symbols 1-7 stand for SYSOP functions. RBBS-PC allows the SYSOP to substitute any symbol for any command. Y)ell may be substituted for O)perator page, or Y)our mail for P)ersonal mail. If a blank is substituted, the command is removed from the list and is no longer available. Since there is no V)iew conference command in the main section, a SYSOP may elect to disable the V)iew conference command in the RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 52 of 232 main section by substituting a blank for it. 8.4 RBBS-PC's "Wrap-around" Command Search ------------------------------------------ There is a special option available in CONFIG which gives the SYSOP unusual flexibility in configuring the user interface. A caller is always "in" a section, that is where RBBS-PC looks for a command that the user requests to see whether it is a valid command. The "wrap around" option controls how RBBS-PC looks further for a command when it is not found in the section the caller is in. If a SYSOP substitutes a blank for the V>iew conference command in the main section (as mentioned in section 9.3) and a user enters the V command from the main section, the V>erbose ARC file list command would be what the caller would have invoked. The fundamental idea is to look further in other sections, where the search order is MAIN->FILE->UTILITY->LIBRARY->GLOBAL->SYSOP and the search is circular, more like ,-->- SYSOP --> MAIN -->---. | | | | GLOBAL FILE | | | | `-<- LIBRARY -<- UTILITY <-' The current section determines only where the search starts. If roll- around is used, the search will go completely around. The real reason that "global" commands are global is that that RBBS-PC always searches after the library section if a command is not in the current section. SYSOP commands are therefore global for the same reason. The important feature that roll-around supports is that a command with a unique letter works in all sections. Thus W)ho will work everywhere the same if roll-around is enabled. THIS ALLOWS THE SYSOP TO SUPPRESS SECTIONS. In effect, by enabling roll-around and giving each command a unique symbol, all commands become global and there is no effective difference between sections. This allows SYSOPs to make commands available on a single level and makes it unnecessary to "go" to a section before using a command in that section. 8.5 How to Have a Single Universal Command Line ------------------------------------------------ The command structure within RBBS-PC can be made "flatter" without making it absolutely flat. Suppose, for example, that a SYSOP wants callers to be able to do all file functions without going to a files section. In effect, the file functions are available in the main section, or the file section is merged into the main section. All that is needed to do is to eliminate the overlap in command letters between the two sections. The main section and the file section share the letters D, P, S, and V. V is used to "view" a conference in the main section and "view" what is contained in an .ARCed file. D is difficult because both D)oors and D)ownload are entrenched and natural options. One could leave D for the RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 53 of 232 most frequently used function, say download, then use a special but arbitrary symbol like # for doors. Similarly, V could be left for viewing conference mail in the main section and a special but arbitrary symbol like & for viewing .ARCed files in the file section. S)earch for substrings could be replaced by F)ind since F for going to F)iles is not longer needed. This could be accomplished by disabling F)iles and substituting F for S in the files commands. The main disadvantage is that experienced users will use F expecting to get into the F)iles section and will get a confusing command. Alienating the old users who will try to use F would defeat the purpose of helping them by making it unnecessary to use F to get the file functions. Better to leave F alone and use a new letter like Z for Z)ippy search. P is used for personal mail in the main section as well as personal files in the file section. Leaving P in the main section for personal mail and selecting the special (but arbitrary) symbol * for personal mail in the file section would have the least impact on callers. U has to be upload. Note that Quit could still get one to utilities. Using Q;U we can then disable U in the main menu. If three symbols is too much of an exception we could use W for W)rite user preferences and use the special, but arbitrary, symbol % to find who else is on. Then we could revise the main menu to read R B B S M A I N M E N U ~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- MESSAGES -- -- SYSTEM -- - FILES - - UTILITIES - - ELSEWHERE - [E]nter Message [A]nswer survey [D]ownload [H]elp (or ?) [Q]uit [K]ill Message [B]ulletins [L]ist [%]Who's on [F]iles (Q;F) [P]ersonal Mail [C]omment [N]ew [X]pert on/off [G]oodbye (Q;S) [R]ead Messages [#]DOORS [*]Personal files [W]rite user [S]can Msg header [I]nitial Wel [U]pload preferences [T]opic msg scan [J]oin a conf. [&]View ARC files (Q;U) [V]iew mail waiting [O]perator Page [Z]ippy search [@]Library This menu could be re-written without any apparent sub-sections (by using the letter F to find who else is on) as R B B S M A I N M E N U ~~~~~~~~~~~~~~~~~~~~~~~~~~~ [A]nswer survey [H]elp (or ?) [P]ersonal mail [U]pload a file [B]ulletins [I]nitial welcome [*]Personal files [V]iew conference mail [C]omments [J]oin conference [P]ersonal mail [&]View ARC files [#]DOORS [K]ill message [Q]uit [W]rite user's preferences [D]ownload [L]ist files [R]ead messages [X]pert on/off [E]nter msg [N]ew files [S]can messages [Z]ippy search [F]ind who's on [O]perator page [T]opic msg scan [@]Library [G]oodby Obviously the limitations of using a single section (as the more primitive bulletin board systems do) means that the number of commands must be restricted to either RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 54 of 232 a.) 26 (letters in the alphabet), or b.) 36 (letters in the alphabet plus the numbers 0 through 9), or c.) full "words". With this artificial limitation of a single section, commands become limited in number, cryptic, or both. If the even more clumsy use of full "words" is chosen, the system must slow down as it can no longer act immediately upon seeing the first character of a command as RBBS-PC does. However, assuming that someone would actually wanted to configure RBBS-PC to be "flat" (i.e. have a single command line), let us continue. In order not to confuse the caller by being in a section and seeing only some of the commands we want him to use, the SYSOP could elect not to show the section in the prompt (CONFIG parameter 37) and not to show the commands (CONFIG parameter 38). Callers would see simply "Your command?" as the prompt. This makes the expert mode pretty terse, but that simply means users would spend more time in novice mode before using expert. Now suppose that only a single command line was desired and that the commands from the "Utilities" menu commands were to be added to the above. The "global" H, ?, Q, and X commands already are in the single command line. M for message margin can remain unchanged since it is unique to the Utilities subsystem. In order to accommodate the redundancy of letters that exist by including the Utilities subsystem's commands, the W command for the main message subsystem can be re-enabled and the remote SYSOPs commands be eliminated in order to re-use the numbers. The Utilities subsystem commands B, C, F, G, L, R, and S could then be replaced by the numbers 1 through 9. The Utilities subsystem commands T, U, E, and P could be replaced by the commands <, >, \, and /, respectively. This final menu of all RBBS-PC commands could be re-written without any apparent sub-sections as follows and the screen that the would appear to the "novice" users as: R B B S C O M M A N D S ~~~~~~~~~~~~~~~~~~~~~~~~ [A]nswer survey [O]perator page [1] Change Baud Rate 300-->450 [B]ulletins [*]Personal files [2] Display time of day [C]omments [P]ersonal mail [3] Set file transfer protocol [#]DOORS [Q]uit [4] Set type of graphics mode [D]ownload [R]ead messages [5] Set page length [E]nter msg [S]can messages [8] Review callers preferences [G]oodbye [T]opic msg scan [9] Display system statistics [H]elp (or ?) [U]pload a file [<] Toggle users options on/off [I]nitial welcome [V]iew conference mail [>] Show the log of callers [J]oin conference [&]View ARC files [@] Library [K]ill message [W]ho's on other nodes [\] Change echo selection [L]ist files [X]pert on/off [/] Change password [M]argin set [Z]ippy search [N]ew files Your command? RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 55 of 232 8.6 RBBS-PC'S Programmable User Interface (PUI) ----------------------------------------------- The programmable user interface (PUI) lets the SYSOP take TOTAL CONTROL what the caller is presented with, including o the novice menu o the prompt line o the organization of commands into groups (sections) o the flow between sections o unlimited levels of nested menus. This allows RBBS-PC interface that the caller sees to take on any appearance desired by the SYSOP. In effect, the SYSOP is limited only by the intrinsic functions of RBBS-PC that have been programmed into the RBBS- PC BASIC source code. These functions can be assigned any command letter desired in the configuration program. PUI lets the SYSOP completely control how these commands are presented to the user - allowing RBBS-PC to "emulate" virtually any other host communications environment that the SYSOP's callers may be familiar with. If no PUI is provided, RBBS-PC defaults to dividing the commands into a MAIN, FILES, UTILITIES, and LIBRARY section. RBBS-PC's PUI gives each SYSOP the flexibility to tailor RBBS-PC to meet special needs. In effect, RBBS-PC's PUI allows the SYSOP to adjust RBBS-PC to what the SYSOP wants, rather than forcing the SYSOP and his callers to conform to RBBS-PC. However, unlike RBBS-PC, the PUI does not adjust the prompt to show only the commands that the user's security level makes him/her eligible for. And, of course, PUI takes much more time to design and implement. When the SYSOP takes control of what the user is presented by using the PUI, RBBS-PC does what the SYSOP has explicitly set up -- and nothing else! For example, RBBS-PC's "global" commands, like help and the expert toggle, are no longer automatically available everywhere. They are available only where the SYSOP has indicated via the PUI. RBBS-PC's default user interface has evolved over the years to represent what the callers found useful (not the SYSOPs!). A great deal of time and thought went into RBBS-PC's default user interface, and it is easy to overlook important things when a SYSOP goes about setting up his or her own. When using the PUI assume that a new user interface will take time to both develop and refine (based on your callers feedback). Designing and implementing a PUI is not a simple undertaking as it is a total replacement for RBBS-PC's standard user interface. 8.6.1 An Example Using PUI -------------------------- The main menu in RBBS-PC can represent a bewildering variety of commands, especially to a new user. Psychologists often say that human beings can RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 56 of 232 effectively deal with only at most 7 choices at one time, whereas RBBS-PC has 17 in its main section. To help people out in this situation, the different choices in RBBS-PC are grouped into related commands, but the choices can still be overwhelming. Some SYSOPs have therefore wanted to simplify the main menu by breaking it up into more sections. The most tempting group of commands to spin off are the message commands. Suppose the main menu is to be simplified to look like: <F>iles <M>ail <U>ser preferences <G>oodbye The <M>ail command in turn puts one in a section where commands pertinent to messages become available in yet another menu, such as J)oin and E)nter. PUI is required because the commands are grouped into different sections. While the default menu of RBBS-PC could be edited to say this, the underlying commands would not be grouped as desired. 8.6.2 How to Implement PUI -------------------------- First, plan carefully on paper exactly what you want the caller to see and what happens with each command. Consider also, if you have a submenu, how users are to get out of it. Each menu or section of PUI is controlled by a file whose extension is "PUI". The PUI is installed by putting a "main" PUI file whose name is specified in the configuration program. The default is "MAIN.PUI". Each sub-board in RBBS-PC can have a different PUI system if desired. A PUI file consists of exactly 10 lines, and the format is: line 1: <name of novice menu> line 2: <prompt to display> line 3: <valid commands>,<corresponding RBBS-PC commands> line 4: <which valid commands are menus> line 5: <names of PUI's that are menus> line 6: <letter of quit command> line 7: <prompt for quit command> line 8: <valid sub-commands of quit command> line 9: <which quit commands are PUI's> line 10: <names of menu PUI's in quit command> The text in the lines should NOT be enclosed in quotes, except possibly the two parts of line 3. The novice menu is just a text file displayed to novices, just like the default menus (MENU1, MENU2, etc.). The name can include a drive or path as well as an extension. The menu PUI's in lines 5 and 10 must be stored in the same drive/path as that in line 1. The prompt to display is what all callers see when asked for a choice, including experts. Normally this includes a brief listing of the commands available along with a request for a command. This prompt is NOT dynamically adjusted to reflect the security level of the caller, unless RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 57 of 232 the default prompt in RBBS-PC, which removes commands the caller cannot execute. Each PUI defines a "section" of RBBS-PC (just like RBBS-PC has a default section of main, file, library, and utilities). The valid commands are the symbols for the acceptable commands in this PUI section. They must be upper case only. The first part is the names of the commands that the caller must give. Each symbol must be mapped to a corresponding internal symbol name in RBBS-PC which is set in CONFIG. This way the same letter in a given menu can be used for different commands in RBBS-PC, just as "S" stands for S)can messages in the main section and S)ubstring search in the files section. Since the default underlying RBBS-PC commands use the same letter in different menus, you should first reconfigure RBBS-PC to assign each RBBS-PC command a different underlying symbol. Then in the PUI file map the letter you want the caller to use to that underlying symbol. Be sure in configuration NOT to limit commands to the current section -- you must let RBBS-PC search in other sections for underlying commands when it does not find it in the current section. In addition to the normal commands available in RBBS-PC, the SYSOP can include new commands which invoke other menus. These must be symbols in the list of valid commands. If a valid menu choice is picked, there must be a PUI file for that choice. Line 5 tells what prefix the PUI file has. Each PUI name must consist of exactly 7 positions. The PUI name can be shorter than 7 letters, but in the list you must blank fill out to 7 positions to the right. The first 7 characters are for the first valid menu command, the second 7 characters are for the second valid menu command, etc. RBBS-PC will automatically append the extension "PUI" to this file name. The file name can include trailing spaces, and must if shorter than 7 characters (any blanks in the name will be omitted). Note that all PUI files must be in same drive/path as the novice menu in line 1. The last 5 lines in the PUI file concern how control goes from one PUI to another. The PUI processing supports a "quit to" command in which the caller can jump to other menus - which one is specified in the subcommands to the quit command (just like RBBS-PC's "quit" to command). Line 6 is the symbol (in the valid commands) which is the quit-to command. It must be a single capital letter. Line 7 is the prompt for the quit-to command, to be presented to callers after they select the quit-to command (type ahead is supported). Line 8 is the list of the valid sub-commands of the quit-to command. Each command must be a capital letter. Line 9 tells which of the valid subcommands are pui commands. If a sub- command is valid but not a PUI command, control will be passed to RBBS-PC to process the quit-to command. For example, Quit-to S)ystem for hanging up would have to be processed this way. Line 10 tells what are the names of the PUI files for each PUI command in line 9. The format of the PUI names is exactly the same as in line 5 -- 7 RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 58 of 232 characters blank filled to the right if shorter. The following file MAIN.PUI installs the example that was discussed in the previous section: MMENU Enter choice: <F,M,U,G> FGMU FMU FMENU MAILM UMENU <blank line> <blank line> <blank line> <blank line> <blank line> The name of the menu to be displayed initially is MMENU. The prompt users will see is "Enter choice: <F,M,U,G>?" (RBBS-PC adds the trailing "?" for prompts). The four valid commands are F, G, M, and U. Three of these commands invoke other menus (F, M, and U), and G is a non-menu command, i.e. one of the base RBBS-PC functions. The PUI file name for "F" is FMENU.PUI, MAILM.PUI for "M", and UMENU.PUI for "U". Each of these PUI files gives the same type of information as the main PUI. For example, MAILM.PUI might contain MAILM.MNU Enter choice: <E,J,P,Q,R,S,T> EJPQRST Q MAIN The novice menu for the mail section is in file MAILM.MNU. This file might contain the following text: M A I L S U B S Y S T E M ~~~~~~~~~~~~~~~~~~~~~~~~~~~ E)nter a message J)oin a new message base P)ersonal mail (review) Q)uit to main section R)ead messages S)can msg headers T)opic msg scan The prompt will appear immediately below this line unless an extra blank line is included in the menu file. There is only one menu command: Q for getting back to the main menu. The PUI system can also be used to emulate the default RBBS-PC commands with 4 sections. Four sample files are provided for accomplishing this: XMAIN.PUI, XFILE.PUI, XUTIL.PUI, and XLIBR.PUI. For novice menus, each uses the standard default menu that comes with RBBS-PC. These presuppose that RBBS-PC has been configured with the following symbols for the underlying RBBS-PC commands: RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 59 of 232 MAIN = normal: ABCDEFIJKOPRSTUVW reconfigured: ABC>EFIJKOPRSTU\W FILES = normal: DGLNPSUV reconfigured: DGLNYZ^V UTILITY = normal: BCEFGLMPRSTU reconfigured: !#E$<&M*()-+ GLOBAL = normal: H?QX reconfigured: H?QX SYSOP = normal: 1234567 reconfigured: 1234567 LIBRARY = normal: ACDGLSV reconfigured: []{G}:' 8.7 RBBS-PC's Support of Sub-menus ---------------------------------- Sub-menu support means that an item on a menu can itself be another menu, so that selecting it results in a new menu being displayed from which the caller can select yet another option. The areas in RBBS-PC that can have sub-menu support include: answering surveys, bulletins, doors, joining a conference, and the file subsystem command to list directories. A primary use of sub-menus is to simplify the user interface, chiefly by allowing sub-categorization of the option. For example, suppose a SYSOP has a complex system of doors, including multi-user games (TREK, NAPOLEON, 3DCHESS), single-user games (D&D, R&R, PICKUP), and demonstrations (DBIII, ORACLE, ADVENT). These could be presented on a single menu, such as The following Doors are available: Multi-User Games TREK - explore the galaxy, compete with 12 other players NAPOLEON - be Russia, Italy, or England and fight the computer 3DCHESS - are you ready, Spock? Single-User Games D&D - the Unix dungeons and dragons! R&R - welcome to Taipei, Tokoyo, or Bangkok, soldier! PICKUP - do you have what it takes? Demos - all self running DBIII - Special version of DB3 adopted for remote usage ORACLE - see the power of SQL. Full screen if you emulate ANSI. ADVENT - our own home brewed ... With sub-menus, the user could see a single, 3 item menu Doors are available for: MGAME - multi-user games SGAME - single-user games DEMO - self running demos When the caller picks one of these three, a new menu comes up that lists the particular doors for each category. For example, after picking MGAME RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 60 of 232 the caller sees Multi-User Games available include: TREK - explore the galaxy, compete with 12 other players NAPOLEON - be Russia, Italy, or England and fight the computer 3DCHESS - are you ready, Spock? RBBS-PC's sub-menu capabilities allow SYSOPs to set up "tree-structured", "key word" paths to options. Bulletins provide an example where this type of structure can be very useful. Bulletins have two main uses: short, system-wide announcements, and a standard stock of text files for policies and procedures for a RBBS-PC. Some SYSOPs, however, have wanted to put up an elaborate system of announcements, where in fact these "bulletins" are a featured way of presenting data to callers. For example, an association published 300 short pamphlets under a dozen categories, and wants to make this information available on-line. Sub-menus fit this need very well. The top bulletin menu could read Bulletins are available for: NURSES - nurses OB - obstetricians PED - pediatricians FAM - family physicians Please type in the category you want: OBS, instead of being a bulletin, is a sub-menu that displays: The following bulletins are available for OBSTETRICIANS Each entry shows the length and price per glossy copy. NAT - natural childbirth, 8 pages, $3 MIDW - midwives. 20 p., $5 NUTRI - special nutritional needs of pregnant women, 25p, $6 FPLAN - family planning services, 40 p, $3 DRUG - drugs to beware when pregnant, 50 p., $5 When the caller picks MIDW, the associated document is displayed. Bulletins become a menu-driven way of selecting documents to browse. There are four general changes to the commands when utilizing RBBS-PC's "sub-menu" features. First, to get the menu displayed when in expert mode, the caller selects the L)ist function. Second, the menu processing routine will search for a file associated with the option selected. Bulletins and file directories will be displayed to the user. These are essentially "display" functions. If a conference exist with the name specified, RBBS-PC will attempt to join it. If a door exists AND it is on the menu, RBBS-PC will attempt to invoke it. This means that the option does not have to be listed explicitly in the menu. Options can be hidden from the user and still work (except for doors). A RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 61 of 232 "secret" conference can be available only if the caller already knows the name. Third, the prompt is more standardized. Fourth, the standard way to get out of the menu is just to press [ENTER]. The bulletins function has been generalized so that bulletins can use names and not just numbers. For example, selecting "B" as the bulletin prefix, the above bulletins would be files BNAT, BMIDW, BNUTRI, BFLAN, and BDRUG. However, the search for new bulletins works properly only if numbers are used to name bulletins, and the prompt for bulletins simply asks for the bulletin and does not mention any numbers. 8.7.1 How to Implement Sub-menus -------------------------------- If "XXX" is an option on a menu, simply create a file named "XXX.MNU" that has in it the text for the menu. Put this file in the same drive/path as the non-menu options (e.g. where the "BAT" files go for doors, where the bulletin files to display are put, where the directory files are). For example, if "B" is the bulletin prefix, the above example would be implemented by adding the files "BNURSE.MNU", "BOB.MNU", "BPED.MNU", and "BFAM.MNU". Put these files on the same drive that the bulletins themselves go. Callers can list any menu at any time as long as the menu they wish to list has the qualifier "MNU". For those menus that the CONFIG utility does not allow the SYSOP to enter a qualifier, the SYSOP can use an editor to edit the .DEF file and add a qualifier directly. 8.8 RBBS-PC's "Macro" Command Support -------------------------------------- RBBS-PC's "macro" support expands a single keystroke into multiple keystrokes. It allows RBBS-PC to be tailored in even a greater variety of ways than before because a single command can be set up to invoke a sequence of multiple RBBS-PC commands. The concept is similar to that pioneered by Prokey, except that in RBBS-PC the SYSOP defines the macros and the caller invokes them transparently without knowing. Macros are an extension of the effort in RBBS-PC to give the SYSOP control over the user interface. RBBS-PC allows the SYSOP to substitute any letter for any command, to group the commands in any way desired, and to have unlimited submenus. Macros give the SYSOPs the ability to create and mold their RBBS-PC into an unlimited variation of commands. RBBS-PC's "macro" command facilities frees every SYSOP from having to impose the rigid and inflexible command structure on their callers that other more limited PC-based bulletin board systems impose. Macros add a new dimension to RBBS-PC commands -- commands can be a full word rather than just a single letter. A macro is invoked by a name up to 8 symbols. For example, "DOOR" and "OPEN" can be used to invoke doors. This makes it easy to make all commands available on a single level. For example, the otherwise irreconcilable conflict between "Download" and "Door" can be resolved by using the full word "DOOR" for doors. RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 62 of 232 Macros can be used to abbreviate a longer series of commands. If the SYSOP wants to use "A)bandon conference", all that need be done is is to add a macro called "A" whose content is "J M" (join main). Or if N)etmail is to be used to read Fido-net compatible message bases, a macro called "N" could be set up as "D NETMAIL" (use door called NETMAIL). Since doors are unlimited in nature, RBBS-PC thus can have UNLIMITED commands. A string of RBBS-PC commands can be stored in a macro for many different types of purposes, including (but not limited to) setting up demos, or showing a suer what to do rather than just explaining it in words, or automting testing when doing RBBS-PC development, or automating a check-out of all of the RBBS-PC functions. Macros can also be used to make the same type of unction do different work. For example, the B)ulletin command basically displays a text file. Suppose an association wants to let persons order pamphlets and preview them on- line. Rather than bury the ordering function insider A)nswer questionnaire and the preview function inside B)ulletins, the commands PREVIES and ORDER can be added as macros, where ORDER stands for "A ORDWHAT" AND "ORDWHAT" is a submenu listing what all can be ordered, and each option on the submenu is a questionnaire. PREVIEW similarly is "B PREWHAT" where "PREWHAT" is a submenu listing the available pamphlets they are stored as text files. Macros have security levels built into them to control access, just like regular commands. Macros are not memory resident and cannot be invoked everywhere inside RBBS-PC. They are supported in only two contexts: 1.) the general command line prompt, and 2.) the programmable user interface. Macro commands with more than one letter override all others. This means that the macro interpretation will prevail if more than one interpretation is possible. For example, in the absence of macros the command "door" would the interpreted as the command "d", so that saying "door" in the files section would be download. But a "DOOR.MCR" would be executed instead when it exists. One letter commands, however, will be executed when they match a command letter, and so any macros will be ignored that have the same one letter name the same as a command. The first line in a macro simply REPLACES the macro name and therefore operates in its place. If PREVIEW is typed in and the first line is "B" for bulletins, then "B" will replace "PREVIEW" and the command will proceed exactly as if "B" has been typed instead of "PREVIEW". Subsequent lines in a macro are stored in a buffer and read off as it they were typed. Realize that in reading everything is read in a line at a time, i.e. up to a carriage return. RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 63 of 232 Two configuration parameters must be specified: the drive/path where macro files are stored and the extension the macro files will have. The default names are "C:" and "MCR". To create a macro named X, simply create a file with prefix X and the macro extension and place in it the macro drive/path. The first line of a macro must be the minimum security level to use the macro. The macro will simply be ignored if the caller has insufficient security. The second line will be parsed and replace the macro name. The remaining lines will be placed in the stack and will be read in as if typed. Suppose A)bandon conference is to be implemented in RBBS-PC. To do this, the command A)nswer questionnaires must be assigned a different letter. Else A will always invoke answer instead. Then the macro file could contain 5 J M The command "A" will then be followed by "Rejoining MAIN". Incidentally, if the macro had been implemented by 5 J M The only difference is that the prompt for what conference to join will be displayed, "M" then would be displayed as if the caller had typed it, and then main would be rejoined. The difference is caused by the fact that the first line after the security level is what replaces the macro name, so in the first case "M" pre-empts the prompt but not in the second. 8.9 RBBS-PC's "Smart" Text Files -------------------------------- RBBS-PC's lets the SYSOP "personalize" such text files as MENUS, Bulletins, Help, and Welcome files. This allows the SYSOP to present to each caller an interface that is not only "programmable", as discussed in section 8.6, but also tailored to the specific caller. To utilize RBBS-PC's "smart" text files, CONFIG parameter 17 must be set to the decimal value of a delineation character that the text editor used by the SYSOP can handle. The character you select should have three characteristics: 1.) It should be visible on the screen and when printed. This allows the SYSOP to see where the control sequence is when designing the text files to be used as "smart" text files. 2.) It should not be a character that might be used for any other purpose in the text files. 3.) It should not be a character that might be interpreted, when printed, as being a printer command (i.e. start double spacing). Some may like to use characters created by simultaneously pressing two keys RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 64 of 232 such as the "Ctrl" and "N" keys to create a character whose decimal representation is 14. Others may wish to use such seldom used, single keystroke characters as: Character Decimal Value @ 64 ^ 94 ~ 126 { 123 <--- Default used by RBBS-PC } 125 | 124 CONFIG parameter 17 can have any value between 0 and 255. If 0 is selected, RBBS-PC's "smart" text capability will be turned off. A RBBS-PC "smart" text control sequence consists of the control character that was selected in CONFIG parameter 17 followed by a "smart" text double- character command. These "smart" text double-character commands MUST be entered as upper case characters! The "smart" text double-character commands are: COMMAND MEANING BD Displays the bytes downloaded today. CS Overrides RBBS-PC's automatic screen depth management so that the next "PRESS ENTER TO CONTINUE" will not come halfway through a page. C0 Resets color to the user's selection for text. C1 Changes color to the user's selection for Foreground Color One. C2 Changes color to the user's selection for Foreground Color Two. C3 Changes color to the user's selection for Foreground Color Three. C4 Changes color to the user's selection for Foreground Color Four. DB Inserts the total number of bytes ever downloaded by the caller. DD Inserts the total number of files downloaded by the caller today. DL Inserts the total number of files ever downloaded by the caller. DT Inserts the current date, MM-DD-YYYY, into the text file. FN Inserts the user's FIRST NAME (in caps) into the text file. LN Inserts the user's LAST NAME (in caps) into the text file. NS This causes the rest of the current file to be displayed in RBBS- PC's "none stop" mode. Page breaks will be ignored following a NS command. PB Causes RBBS-PC page break message, "MORE (Y/N/NS/A)" or the "PRESS ENTER.." prompt to appear after the line is printed. RP Inserts the number of days in the registration period. RR Displays the days remaining in the caller's registration period. SL Inserts the user's current security level into the text file. TM Inserts the time (hh:mm AM/PM) into the text file. TE Inserts the user's elapsed session time (hh:mm) into the text file. TR Inserts the number of minutes left in the user's session into the text file. UB Displays the total number of bytes ever uploaded by the user. UL Displays the total number of file ever uploaded by the user. When designing "smart" text files, each SYSOP should take into account that the some of the "smart" text commands (i.e. the user's name) may RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 65 of 232 significantly extend the length of a line . It is important that this line elongation be taken into consideration so that, when the actual text substitution occurs, the line seen by the caller does not exceed 80 characters. What follows is an example of a "smart" text file that demonstrates how all of the above commands might be used. The following example assumes that CONFIG parameter 17 has been set to the decimal value 123 for the "smart" text delineation character -- {. INTRODUCING SMART TEXT! RBBS-PC allows the SYSOP to customize the text seen by each caller. For instance, if the SYSOP wanted to make sure this message didn't scroll off the screen, he could pause the display like this:{PB Or, the SYSOP may want to show the caller that today's date is {DT and the time is {TM. The SYSOP may even want to include a personal greeting to {FN {LN. The SYSOP can tell the caller that their security level is {SL and that they have been on-line for {TE, and have {TR minutes left in this session. This kind of capability illustrates RBBS-PC's on-going commitment to nurturing each SYSOP's creativity and avoiding the dogmatic. 8.10 "Colorizing" the RBBS-PC User Interface -------------------------------------------- "Colorization" refers to the utilization of color within RBBS-PC text files and prompts. RBBS-PC has long supported graphics versions of external text files, and is even distributed with graphics menus. RBBS-PC supports "colorization" as follows: 1.) In files shown to the callers including: All menus, All bulletins, The Welcome file, The file for new users, All on-line help files, Standard file directories, and FMS file directories (see item 6). 2.) Via highlighted text in searches of messages, in searches of files, in announcing new personal mail waiting, for locked out users, and the SYSOP user maintenance (function 5). Highlighting supports a limited but extremely functional use of colorization - to make it easy for the caller to spot significant bits RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 66 of 232 of text on a screen. 3.) Within the Programmable user interface (PUI). The PUI file can have graphics versions just like text files. The file XMAIN.PUI that was used in the example in section 8.6.2. can have a graphic's equivalent named XMAING.PUI and a color equivalent named XMAINC.PUI. Color codes can be embedded in the prompts in the PUI as well as external text files. Each SYSOP has total freedom to colorize prompts as well as menus. 4.) Within text internal to RBBS-PC. This applies to standard (non-PUI) prompts, such as the main command prompt, and to formatted reports, like the message scan and message read. This type of "colorization" is controlled by whether highlighting has been turned on in CONFIG. 5.) Within RBBS-PC's "short" prompts. Caller foreground color 4 is used to mark the commands the user can type. Emphasis is used to mark the default selection. This colorization is based on a scan of the text to be printed: [...] : will be highlighted (default answer) xxx) : will be put in foreground color 4 (text to type in): if xxx is not longer than 2 characters and is in caps <...> : will be put in foreground color 4 (collective choices) and if there are words before this, 1st will use foreground 1 and second foreground 2. "Short" prompts colorization applies to ALL text displayed by RBBS-PC before an answer is expected. For example, by using the above conventions, questionnaires can be colorized. This is controlled by whether highlighting is on. 6.) Within FMS file directories. The "colorization" of the FMS file directories is based on the four colors specified in CONFIG and is controlled by whether or not the caller has selected to be in color graphics mode or not. There are two extremes on the use of color -- use none or use everywhere. By using no colorization, RBBS-PC's performance is optimized. RBBS-PC does not have to go through the overhead of transmitting special instructions to control the caller's screen. The two chief functions of boards - transmission of textual information and file exchange - do not essentially involve the use of color. Thus "colorization" is at best dispensable and at worse degrades the performance of these essential functions. Of course, there are those who want their RBBS-PC's visual displays to convey as much as the text or the files themselves (i.e. the message is in the medium). These are the SYSOPs would elect to use color everywhere. Color is largely used to group related information on the screen, where everything has a color. With the use of color, plain text begins to look drab and uninteresting and attention tends to focus on the colorized text. For this reason, some SYSOPs find it difficult to use color in some places and not in others. RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 67 of 232 If "colorization" is activated everywhere within RBBS-PC it is imperative that the PRELOG or WELCOME file inform callers to execute the G)raphics command. RBBS-PC's default is to use "colorization" for internal prompts. The G)raphics command ask users: 1.) If they want graphics versions of text files, 2.) Whether the caller wants prompts colorized, 3.) What color the caller wants for normal text, and 4.) Whether normal text should be bold or normal in intensity. To Implement "colorization" within RBBS-PC, run CONFIG and go to screen 17 of the CONFIG parameters -- "RBBS-PC Color Parameters". 1.) Use CONFIG's parameter 321 to put in a string for for turning EMPHASIS on. The recommendation is a bright foreground on red background ("[27][1;41m"). 2.) Use CONFIG's parameter 322 to set the string for normal text. This is the general default color and is used to turn off emphasis. The recommended color is amber (normal yellow) ("[27][0;33m"). 3.) Use parameter 323, parameter 324, parameter 325, and parameter 326 of CONFIG to set the four caller foreground colors. CONFIG uses natural language phrases to set these, so it is very easy. The recommendation, in order, is: bright green, bright yellow, bright purple, and bright cyan. These colors are all used in the message header and general command prompt. Foreground 4 is used to highlight the commands the caller actually needs to type in to select that option. No colors will be displayed if these parameters are set to empty strings. Callers can turn off the colorization simply by going into Utilities and T)oggle H)ighlite to "off". The default in RBBS-PC is for colorization to be OFF. Colorization is based on the ANSI standard. Special codes are sent by RBBS-PC to the callers system, which must then be interpreted by the caller's communications software. CONFIG lets the SYSOP set the strings to turn color emphasis on and off. Inside the PUI and external text files, the SYSOP must use an editor to create graphics files. There are special graphics editors, like THEDRAW, or a SYSOP who knows the codes to embed can use an ordinary text editor. The reason that colorization cannot be used with FMS directories is that adding in color codes changes the length of the lines and shifts columns from the position RBBS-PC expects the file to be in. However, color codes can be embedded in free text files in an FMS. It is important to remember to keep each line within an FMS a fixed length. RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 68 of 232 8.11 RBBS-PC's Automatic Operator Page Option --------------------------------------------- RBBS-PC will "automatically page" the SYSOP whenever a specified caller or group of callers logs on to RBBS-PC or joins a specific "conference" (i.e. "sub-board"). The selection criteria be a specific caller's name, a range of security levels, or whether the caller is a new user. A SYSOP may wish to be notified for any number of reasons including: The SYSOP wants to chat with caller or that caller has been causing trouble on the bulletin board and needs to be monitored, The SYSOP wants, for security reasons, to be notified when anybody logs on with a SYSOP security level. The SYSOP wants to chat with a friend but does not want to continually monitor RBBS-PC's activity. Automatic paging of the SYSOP is controlled by a file whose name is specified in CONFIG parameter 18 (the default name is AUTOPAGE.DEF). This file contains 4 parameters separated by commas. The format is <condition>,<notify caller?>,<# of times>,<music> <condition> can be a NAME enclosed in quotes, the string "NEWUSER", or a security level range specified in the format /<min sec>/<max sec> where: <min sec> is the minimum security level to include <max sec> is the maximum security level to include <notify caller?> is "N" if the caller is to also be notified that the SYSOP wants to be automatically paged when the caller logs on. Anything else means the caller will not know that the SYSOP has been paged automatically. <# of times> is the number of times that the PC's speaker will be sounded. <music> is what is to be played each time the speaker is sounded. If nothing is specified, a beep will be used. Examples: "SEXY DEVIL",,3,DEL2CL4EDC means to automatically page the SYSOP when a caller named SEXY DEVIL logs on, not to notify the caller, and to page the SYSOP three times playing "DEL2CL4EDC" each time. "GREGG SNYDER",N,2, means to automatically page the SYSOP when GREGG SNYDER logs on, to notify the caller, and to beep the SYSOP twice. "NEWUSER",,1, means to automatically page the SYSOP when any new caller logs on, not to notify the caller, RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 69 of 232 and to page the SYSOP once. /10/12,N,3, means to automatically page the SYSOP when anyone with security 10 through 12 inclusive logs on, to let them know that the SYSOP wants to be notified that they are on, and to beep the SYSOP twice. The status line at the bottom of the screen will read "Autopaged!" if RBBS- PC has automatically paged the SYSOP. This allows the SYSOP to know that the automatic page took place, even if the SYSOP was not present at the beginning of the call. The following is a sample AUTOPAGE.DEF: "SEXY DEVIL",,5,DEL2CL4EDC "GREGG SNYDER",N,2, "NEWUSER",,1, "/10/12",N,3, If more than one condition will trigger the automatic paging of the SYSOP, the first condition encountered will be used. Since the AUTOPAGE.DEF file can be different for each "sub-board", the SYSOP has the option to be automatically paged based on different criteria for each "sub-board". 9. PLANNING ON HOW TO UNIQUELY IDENTIFY YOUR CALLERS ----------------------------------------------------- All callers need a way to identify themselves and to re-identify themselves on subsequent calls so that they can, for example, read the mail addressed to them. RBBS-PC expects each caller to set a password so that other callers cannot easily pretend to be that caller. Callers are most easily known on bulletin boards the same way they are known in real life - which is usually by first and last name. This is why the default configuration in RBBS-PC uses first and last name to IDENTIFY users. The first/last name is the callers identify or ID. RBBS-PC also allows the SYSOP to identify callers uniquely by something other than their first and last names. Perhaps the SYSOP wants a one word alias like AVENGER to be allowed or perhaps callers must use a preassigned access code (access code, employee number, account number, etc.). RBBS-PC allows ANY FIELD inside the users file to be used for identification. Since there are empty, unused areas in the user file, a SYSOP can even CREATE A NEW FIELD to be used for caller identification. When anything other than name is used to identify users, RBBS-PC still wants callers to specify their names. It just does not use that information to identify them. A fairly common problem on bulletin board systems with large user lists is that two callers can have the same first and last name. A caller discovers this when they are unexpectedly asked for a password on the first call to a new system, indicating that another caller has already used that name. Further, since RBBS-PC is used world-wide many non-English speaking countries (i.e. in Europe, South America, the Far East) have callers with RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 70 of 232 names that have embedded blanks, etc. RBBS-PC alleviates this problem by allowing interior blanks in first and last names. Thus JIM JONES can register as JIM K JONES or JIM JONES SR or JIM JONES III. By allowing ANY field inside the user record to be used to uniquely identify individual callers, RBBS-PC alleviates the basic problem of having two callers with the same name. This additional INDIVIDUATION field is used to distinguish callers with the same ID. The way this works is that callers will have to specify both the identifying and individuation field and both are used to match record in the users file. This individuation field can likewise be a new field created by the SYSOP. For example, the SYSOP can specify that callers be uniquely identified by both their name and their CITY/STATE. Alternatively the SYSOP can specify that callers are to be uniquely identified by their telephone number, which would be a new field for RBBS-PC to store. 9.1 How to Set Up Identifying and Individuation Fields -------------------------------------------------------- The identifying and individuation fields in RBBS-PC are controlled by parameter 41, parameter 42, parameter 43, parameter 44, parameter 45, and parameter 46 in CONFIG. The default is to use the caller's first and last name to uniquely identify a user. The fields available to uniquely identify a caller (other than the caller's first and last name) are designated in CONFIG by the starting position in the users file and length. It is essential therefore to understand WHERE FIELDS ARE STORED IN THE USER FILE. Consult Appendix A for the detailed layout of the user file. RBBS-PC's flexibility requires caution to be exercised when selecting the locations of fields used to identify and individuate, because options can be selected that make no sense. For example, it is possible to specify the user preference field, which means that every time a user changed preferences, such as default protocol, the user would become a different user. There are only two fields in the user file that make sense for identifying users: 1.) first/last name (column positions 1-31), or 2.) a field designated by you as the SYSOP for your RBBS-PC. For a SYSOP-designated field, only 4 choices make sense: a.) none, b.) name (columns 1-31), c.) city/state (columns 63-86), or d.) positions 87-97 in the user record currently "unused." Positions 87-97 of the users file currently unused provides a potential 11 columns to use for special, SYSOP designated fields. However, there is no guarantee that these positions will not be used in later releases of RBBS- PC. Additional fields will be used from the far right. Any SYSOP intending to utilize this area of the users record is safest if the field selected begins in column 87 and is as short as possible. The shorter it RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 71 of 232 is, the more likely there will be room in later releases. For example, 11 columns might be used for telephone number (format 123-1234567). Or 5 columns might be used for account number. When a special field is created, the SYSOP must also supply the prompt to be used with the field, since RBBS-PC has no way of knowing how to describe the field to a caller. The prompt is what is displayed to the caller when asking for the value of the field. RBBS-PC uses the callers first and last name for the "to" and "from" fields for messages even when the users name is not the field used to uniquely identify callers. 9.2 PRELOADING IDENTITIES FOR INSTANT ACCESS ---------------------------------------------- SYSOPs that operate bulletin boards that are open to new callers have no problems giving a new caller instant access -- new callers register, set their identity and password, and are immediately on. SYSOPs that operate bulletin boards that are only available by subscription or who delay access operate differently -- a user must already know and be able to state identity, individuation, and password in order to get on. To add a new user, the values of these fields must be communicated back to the caller in order for them to have access. To overcome this cumbersome approach, some SYSOPs allow new callers on their system (albeit at a security level so low that the caller can do little, if anything) and simply raise the security level of the caller once the caller has met whatever criteria the SYSOP has set for access to the system. Typically new callers must call back and continue to check to see if their security level has been raised. Systems that do not let new callers on require the SYSOP to enter the appropriate information for each new user, contact the new caller by mail or phone, and let them know how to get on. Both approaches introduce delays to new callers for getting on and additional time, expense and overhead for the SYSOP. RBBS-PC provides a systematic solution to the problem of delayed access for new user! A SYSOP can add a user WITH NO VALUE FOR THE INDIVIDUATION FIELD OR PASSWORD. These fields can be left blank. When a caller logs on with a proper ID and RBBS-PC finds an individuation value or password that is blank, it lets the caller set the value of those fields without requiring a match. Subsequent calls, but not the first, must match the value set for individuation and password. Even though a SYSOP can add a user and leave the password and individuation blank, this still requires that the SYSOP add the user only after an ID is agreed to by both parties. What if this access is still not fast enough? The solution provided by RBBS-PC is for the SYSOP to "pre-load" IDs and give out a pre-loaded ID to the caller for instant access, so that the client does not have to wait even for the SYSOP to add the ID. Since there is no way to set in advance how a user wants to be identified, the SYSOP can set up essentially random account IDs which are difficult to guess and give these out. RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 72 of 232 Callers willing to charge subscription fees on their credit cards over the telephone can be given a valid pre-loaded ID for instant access. The ability of RBBS-PC to use any field for an ID, and let the first call set individuation and password, means that RBBS-PC can support boards where instant access is a critical part of their service. 10. RBBS-PC's AUTOMATIC SUBSCRIPTION AND TIME MANAGEMENT SYSTEM ------------------------------------------------------------------ RBBS-PC has support built into it for managing access based on the date of the call and the time of day. As with the other RBBS-PC features, this support is optional. The primary uses of this facility are 1. to make it very easy to control access based on subscription dates. 2. to give callers a temporary, date limited boost in privileges. 3. to vary the amount of time that a call can have for a session based on the time of day. The subscription management system dramatically reduces the work necessary for subscription maintenance. After a user is registered, RBBS-PC will AUTOMATICALLY 1. warn users before their subscription expires 2. reduce the security of callers whose subscription has expired. In effect, a subscription RBBS-PC can be left on "automatic" pilot and it will operate correctly, without additional effort on the SYSOP's part. The subscription and time management system can also be used to grant callers a temporary boost in privileges. For example, giving new callers a "free" trial period. Just as cable TV channels that sometimes have a free week of viewing to attract new subscribers by letting them know what they are missing, a SYSOP of a subscription RBBS-PC can set up limited free offers. By setting up a default subscription period of say, 5 days, all new callers can be let onto to see whether they want to subscribe. After 5 days, security drops back down to a more limited level. This "free" period can be made a standing offer, or turned off after a two week period. Or, a user who requests a trial period can be individually added with a short subscription period. Limited trial subscriptions also are an attractive alternative for those SYSOPs that do not give full privileges until after a caller is verified or checked out. These callers are either asked to fill out a registration form or leave a comment, then sometime later the SYSOP decides whether to increase the security level. By letting new users have a short registration period with higher privileges, say 3 days, a SYSOP may choose to give new callers immediate access and minimize the pressure to check the new caller out as soon as possible. The SYSOP need do nothing if a caller cannot be verified. Those that check out get their security raised. This way the many honest new users are not penalized but the prank or dishonest callers can get on only briefly. RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 73 of 232 10.1 Setting It Up ------------------ The subscription management system is turned on by specifying in CONFIG to limit callers by subscription date. After access is so limited, RBBS-PC automatically records the date of the first call. For old users, this will be the first call made since the subscription date began to limit access. This recorded date is the base registration date. The SYSOP then needs to specify in CONFIG: 1. A default subscription period (the number of days a new user gets). 2. A warning period (which determines when callers will get an advance warning that their subscription is about to expire. The warning period is the number of days left needed to trigger a warning.) 3. The security level expired subscribers get. In the PASSWRDS file, the SYSOP designates different subscription periods for each security level (other than the default security level). This needs to be specified only if a subscription period is desired that will override the default. RBBS-PC determines when the subscription will expire by adding the subscription period to the base registration date. Persons calling after this expiration date are bumped down to the expired security level set by the SYSOP in CONFIG. The time management of RBBS-PC is automatically activated when the presence of the PASSWRDS file is detected. See section 16.3 for a complete description of the PASSWRDS file. 11. USING THE "CONFIG" UTILITY TO CONFIGURE RBBS-PC ---------------------------------------------------- The RBBS-PC.DEF file is created by the CONFIG program and contains the program's default operating parameters and values. When you run the CONFIG program to create RBBS-PC.DEF or to update it, you can change many of these parameters to meet your needs. Certain parameters which control critical operations of the programs are embedded in the RBBS-PC program and should not normally be changed by the system operator. When setting RBBS-PC is set up for the first time, SYSOPs are urged to take the default values generated by CONFIG except for those parameters that are unique to their configuration (i.e. the communication port, etc.). CONFIG.BAS, unlike Gaul, is divided into many parts or screens. They are: Screen Description 1 Global RBBS-PC Parameters (Part 1 of 3) 2 Global RBBS-PC Parameters (Part 2 of 3) 3 Global RBBS-PC Parameters (Part 3 of 3) 4 RBBS-PC System Files (part 1) 5 RBBS-PC System Files (part 2) 6 Parameters for RBBS-PC "doors" 7 Parameters for RBBS-PC Security (part 1) 8 Parameters for RBBS-PC Security (part 2) RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 74 of 232 9 Parameters for Multiple RBBS-PC's and "conferences" 10 RBBS-PC Utilities 11 Parameters for RBBS-PC's File Management System 12 RBBS-PC Communications Parameters (part 1) 13 RBBS-PC Communications Parameters (part 2) 14 RBBS-PC Net Mail 15 New users parameters 16 Use of the Library Sub-System 17 RBBS-PC Color parameters 18 Reserved for future use The user may scroll forward or backward through the 17 screens of parameters in CONFIG using the PgUp and PgDn keys on the keyboard. Additionally users may go directly to a specific screen by pressing a function key (F1 through F10) or SHIFT and a function key (shift/F1 through Shift F7) corresponding to the page to be selected. To terminate CONFIG, users need only press the "End" key on the keyboard. CONFIG can be invoked with the command: CONFIG <config file> The <config file> is an optional name of the configuration file to be created or edited. This assumes that CONFIG.EXE, is on the default disk drive. The CONFIG utility will write the RBBS-PC definition file, RBBSxPC.DEF to the default drive. 11.1 Global RBBS-PC Parameters (Part 1 of 3) -------------------------------------------- Parameter 1 and parameter 2 request the RBBS-PC system operator's (SYSOP) name. This is used when someone wants to leave a message for the SYSOP or when the SYSOP "chats" with someone on-line. The SYSOP name is used to insure that users are not attempting to access RBBS-PC using the SYSOP name hoping to get a higher access level. Attempting to logon using the SYSOP name will result in "LOGON DENIED" and a posting of the attempt in the CALLERS file. The SYSOP's name can be either a real name such as "Tom Mack" or an impersonal identifier such as "Physics Department." The SYSOP's default sign-on mode is set by parameter 3 as either EXPERT or NOVICE. Unless you are very familiar with the RBBS-PC's command structure, the SYSOP's sign-on mode should be NOVICE. The SYSOP can be paged by callers. Parameter 4 allows the SYSOP to set the "office hours" when a user can page the SYSOP. The IBM PC's bell is rather insistent, and these hours should be set to match when you will be within ear-shot of the RBBS-PC. The times are set using a 24-hour military clock (i.e. 10:00 P.M. is 2200 hours). The SYSOP can override these hours by activating the page bell via function key 4 on the keyboard of the PC running RBBS-PC. Because the bell on an attached printer is usually louder than the one built into the PC, the SYSOP can elect to have the printer's bell via parameter 5 whenever the SYSOP is "paged". RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 75 of 232 Parameter 6 gives the SYSOP the option of electing to have RBBS-PC automatically take itself off-line if a "disk full" condition occurs. In previous versions, this was not an option. Now, if the SYSOP has a floppy disk for uploads that gets full and everything else is on a hard disk, the SYSOP can keep RBBS-PC from taking itself off-line should the floppy disk get full. Parameter 7 is the SYSOP's preference for prompt sounds when input is required. When this is on, both the remote user and the local SYSOP will hear the prompt bell when input is required from the remote user. Parameter 8 of the CONFIG program asks for the maximum amount of time each user is to be allowed on the system per session. Set the number of minutes to whatever you are comfortable with, but 72 minutes is a good setting for starting up. Subsequently you may have to lower this number once your number of callers increases, in order to keep callers' waiting times reasonable. This can also be made the maximum time on the system per day. As described elsewhere, each security level can have its own maximum time on the system per session specified and it can vary according to the time of day that the user logs on. A SYSOP may limit the maximum amount of time any user with the default security level can spend on your system each day via parameter 9 of CONFIG. This is helpful if you have a relatively busy RBBS-PC and want to have as diversified group of callers as possible. Every security level can have a different maximum time on the system per day and it may vary based on the time of day that the user logs on. These are specified in the PASSWRDS file. RBBS-PC keeps track of the total amount of elapsed time a user is on RBBS- PC each day. Each time a caller logs on, the maximum amount of time that they are allowed on the system is checked against this daily cumulative total. The time remaining in each caller's session is the difference. When a caller exceeds this maximum and tries to log on again, they are told that they have exceeded the allocated time for that day and to try again tomorrow. Parameter 10 allows a SYSOP to "reward" users who upload files by adding some multiple of the elapsed time it took for the file upload to the current session time. This should be used judiciously as some users may abuse this by repeatedly uploading COMMAND.COM or some other meaningless file. This extends both the users current session and other sessions during the same day, but NOT the time on future days. However when specifying this parameter, the SYSOP will be asked if upload time credits are to accumulate indefinitely until they are used. If the SYSOP replies "NO", the upload time credits endure only for the day in which the uploads are made. Parameter 11 sets the number of months inactivity that must elapse before a user is deleted from the USERS file when the SYSOP "rebuilds" the user file. Parameter 12 allows the SYSOP to specify the name of the RBBS-PC that is to be displayed when a user first connects with the system and prior to RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 76 of 232 completing the logon process. Parameter 13, parameter 14, and parameter 15 allow the SYSOP to specify the colors desired for the foreground, background, and border. When specifying these options the BASIC manual's section describing the COLOR command in text mode should be consulted. This is useful when running multiple RBBS-PC's and you want a handy way of determine which RBBS-PC it is that you are viewing on the screen. This option is NOT available if the SYSOP has specified a "ring-back" system. Parameter 16 control whether RBBS-PC will use ANSI codes for special effects like blinking on the local PC's screen. Parameter 17 designates the decimal value ( 0 to 255) of the character to be used for personalizing the text files displayed to the caller. If 0 is selected, no text files will be personalized. See section 8.9 for a more detailed discussion of how to personalize RBBS-PC text files. Parameter 18 allows the SYSOP to specify the file name that contains the information to control the "automatic" RBBS-PC paging of the SYSOP. See section 8.11 for a detailed description of the file format and a description of RBBS-PC "auto-page" feature. Parameter 19 lets the SYSOP determine the level of detail to use when notifying callers of electronic message. See section 19 to get a better understanding of the full flexibility of mail waiting notification that has been built into RBBS-PC. 11.2 Global RBBS-PC Parameters (Part 2 of 3) -------------------------------------------- Parameter 21 allows the SYSOP to remind users not only of the messages that might be for them but also messages that they may have left. This should be enough of a nuisance to insure that users do delete some of the messages they have left and help to keep the MESSAGES file to a minimum. Parameter 22 allows the SYSOP to elect to remind users of how many files they have downloaded and uploaded. Parameter 23 allows a SYSOP to remind users every time they log on of the preferences they have selected for such things as file transfer protocol, graphics, nulls, etc. Parameter 24 allows users to download files immediately upon logging on to RBBS-PC. Parameter 24 is only meaningful if the RBBS-PC File Management System (FMS) has been enabled via parameter 214. RBBS-PC will scan this file for the latest uploads. When a caller logs on, RBBS-PC will determine how many files are new since the caller last logged on, up to a maximum of 23. By setting parameter 218, the caller is offered the chance to immediately review these new files for downloading, if the caller has sufficient security to download. This happens before the bulletins or messages are reviewed. RBBS-PC's that emphasize software exchange may want to enable this option, others may not want to give the caller a chance to download the new files until after bulletins and messages have been reviewed. RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 77 of 232 Parameter 25 allows the SYSOP to establish a default page length for users when they log on. A 23 line page length is the default, but the SYSOP can set it to any number between 0 and 255. If set to 0, the user will receive continuously scrolling output. Parameter 26 allows the SYSOP to specify (within the range of 1 to 99) the maximum number of lines allowed in each message. Parameter 27 allows the SYSOP to make the system "welcome" file interruptible. The default is that YES it is interruptable. However, if the SYSOP feels too many people are bypassing it and it contains essential information, the SYSOP can set this parameter to NO (i.e. the user can not suspend or cancel the listing of this file at their terminal with a CTRL S or CTRL K). Parameter 28 is intended to allow the SYSOP to indicate if the system bulletins are to be optional for users when they log on. If bulletins are optional, callers can elect to automatically bypass old bulletins and be notified only when there are new bulletins. RBBS-PC will check the file date of the bulletins and inform the caller which are new, with the option to read all of the new bulletins. If none are new when bulletins are optional, the bulletins will be automatically bypassed. Parameter 29 is designed to allow RBBS-PC to run on some "IBM-compatible" PC's that make use of unused interrupts or on the IBM PCjr. RBBS-PC checks to see if the unused interrupt X'7F' is non-zero. If it is, RBBS-PC thinks that the software product, MultiLink (from The Software Link, Inc.) is present and issues the appropriate MultiLink calls. Obviously if this is not the case, strange and unpredictable things happen which result in RBBS-PC not working. The COMPAQ+ is an example of this syndrome. If running RBBS-PC on an IBM PCjr using an external modem but without an internal modem, the communications port must be opened as COM1 even though RBBS-PC must use the COM2 RS-232 registers for controlling the communications port. Parameter 30, parameter 31, parameter 32, parameter 33, and parameter 34 let the SYSOP change what symbols are used for each RBBS-PC function by substituting a new letter. Additionally, a space substituted for a command will disable that command, in effect removing it from the system. SYSOPs with no DOORS may wish to disable D rather than to confuse users by displaying options not available. All commands displayed to callers in the command prompt will be in sorted order. Parameter 35 allows the section name to precede the command prompt that is displayed when a caller is asked to enter a command. The command prompt begins with <section>, where <section> is MAIN, FILE, or UTIL, if this option is selected. Otherwise, the prompt will begin with YOUR. Normally the section in the prompt helps the caller remember where he is, but see section 8 for reasons to suppress the section. Parameter 36 allows the SYSOP to not display the commands to the caller when waiting for the user to enter a command. The default in RBBS-PC is to RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 78 of 232 remind the caller what commands are available by giving a sorted list of the letters used for each command at the end of the command prompt. RBBS- PC shows only the commands available in the section that the caller is in. If the SYSOP chooses not to display the section a user is in, there are more commands available than will be shown in the prompt. RBBS-PC supports a "wrap-around" search for valid commands. This means that when a command is not found in the current section, other sections are then searched. The order of search is MAIN->FILE->UTIL->LIBR. For example, if L is picked when in the main section, where there is no command, the L)ist command in the file section will be executed. Parameter 37 lets the SYSOP turn this wrap-around search and not execute commands in other sections. Wrap-around is required if the SYSOP want's to have a single command line (i.e. not have the "Utility" and "File" subsystems). Parameter 38 allows the SYSOP to elect to use machine language subroutines (rather than the BASIC routines) for a few of the more commonly used subroutines. These may only be functional within a DOS that is supplied by IBM (rather than Microsoft). Therefore this is optional. If you encounter problems, simply elect to utilize the BASIC routines which are much more likely to be compatible in configurations that have hardware and software operating environments significantly different from the "baseline" configuration in which RBBS-PC is tested. In most cases the assembler routines are much faster than their BASIC counterparts, especially in file searches. Parameter 39 allows the SYSOP to elect to use the BASIC language's PRINT statement to write to the screen of the PC that RBBS-PC is being run on. This is sometimes necessary in "hostile" environments (i.e. multitasking, special screen drivers, etc.) where the use of RBBS-PC's default call to the RBBS-PC screen driver ANSI is not viable. Parameter 40 is the maximum number of lines that can be used to describe a file that was uploaded. It is the number of lines (beyond 1) that a caller can enter when describing a file that was uploaded. It applies to both single FMS directories and non-FMS directories. 11.3 Global RBBS-PC Parameters (Part 3 of 3) -------------------------------------------- Parameter 41 and parameter 42 determine how callers are going to be uniquely identified when they log on. The default in RBBS-PC is to concatenate first and last name to form name. Parameter 41 lets SYSOPs choose another field as user ID. A field is specified by giving its starting position and length in the user file, and a prompt must be supplied which will be used when asking for user ID. BE VERY CAREFUL CHANGING THIS PARAMETER. Parameter 45 and parameter 46 allow the SYSOP to specify a name to be used when prompting the user for the field (i.e. ACCOUNT #). See section 9 for additional details. RBBS-PC assumes that name is being used whenever the ID begins in column 1. Parameter 42 lets a field be specified that will be used to distinguish callers with the same ID. Like with ID, the beginning column, length, and prompt must be specified. RBBS-PC defaults to no individuation, which is specified by setting the beginning column to 0. Activating this option RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 79 of 232 forces users to give additional information when they log on, since both ID and individuation value have to be given. See section 9 for details on how to use this option. Parameter 43 and parameter 44 inform RBBS-PC the field and the length of the field in the USERS record to use when determining if a "personal download" exists for this person. Parameter 43 indicates where the field begins in the USERS record -- the default is position 1 (the user's name). Parameter 44 indicates how long the field to match against is -- the default is 31 (the maximum length of a user's name). The entries in the personal download directory must have exactly this many bytes at the end -- plus one (for the flag used to indicate if the file has been download). Parameter 45 and parameter 46 allow the SYSOP to specify the description of what is asked for that is placed in the first 31 bytes of each user's record. When identifying to whom a message is to/for it is these 31 bytes that are matched against. However, these prompts can be changed from the default "FIRST name" for parameter 45 to "REAL FIRST name" or even "DEALER number". Similarly the default for parameter 46 could be changed from "LAST name" to "ZIP code". Parameter 47 allows the user to enforce upload to download ratios. See section 16 for a discussion of the flexibility each RBBS-PC SYSOP has in specifying these ratios. Sections 16.3 and 16.4 describe in more detail the format necessary to use in the password file in order to utilize which users/security levels are to have upload and download ratios applied. Parameter 48, parameter 49, parameter 50, and parameter 51 address access control via the automatic RBBS-PC subscription management facilities. For a detailed discussion of RBBS-PC's automatic subscription management facilities, see section 10. Parameter 48 means that access will be controlled by subscription dates, and persons with expired subscriptions will get reduced privileges. Parameter 49 is the security level callers get after their subscription expires. Typically this security significantly reduces what a caller is allowed to do. Parameter 50 specifies when callers are to be warned in advance that their subscription is about to expire. This warning is based on the number of days before a subscription expires. Parameter 51 specifies the number of days a new user gets in the subscription period. Parameter 52 determines if RBBS-PC is to avoid writing to the printer. On some networks any attempt to write to a printer can generate a spooler error that hangs the node. Setting this parameter to "YES" guarantees that RBBS-PC doesn't write to the printer. Parameter 53 causes RBBS-PC to play musical themes for auditory feedback on what is happening on a board. This can be important for SYSOPs that are sight impaired. These musical themes are "played" on the speaker of the PC that is running RBBS-PC. The themes are not transmitted to the caller. Parameter 54 is the buffer used internally by RBBS-PC when displaying text files such as menus, directories of files, etc. A SYSOP can set parameter 218 to either minimize memory usage or optimize speed. It is the size of the internal buffer that RBBS-PC uses to read in most text files, including RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 80 of 232 menus and can range from 32 bytes to 4096 bytes. The bigger the buffer, the fewer disk accesses necessary to display the file and the faster the display will be. The default of 128 is the minimum recommended. Increasing this to 512 will increase the speed of text displays. However in some environments where it is important to respond quickly to XON/XOFF control, this should be set to the minimum of 32. Parameter 55 allows RBBS-PC to dynamically set the "stack space" used by the code generated by the BASIC compiler. In QuickBASIC 3.0, the compiler used to generate RBBS-PC's .EXE file, and IBM's BASIC Compiler Version 2.0 this is the total stack space. In later releases of QuickBASIC, it is the ADDITIONAL stack space beyond which BASIC normally allocates. The recommended value is 1024, if RBBS-PC is running in a multi-tasking environment under DOS. However, in order to decrease memory demands this can be made smaller. Parameter 56 is not implemented in RBBS-PC. Parameter 57, like parameter 45 and parameter 46, is used when a new user logs on to the system for the first time. Instead of asking a user for their City and State, a SYSOP can request such things as their area code and telephone number. Parameter 58 allows the SYSOP to configure RBBS-PC such that the file directories are shown in sorted order whenever a caller simply lists the directory of directory. 11.4 Parameters for RBBS-PC System Files (part 1) ------------------------------------------------- Parameter 61 specifies the name of text file that is shown to a user if bulletins are not optional (see parameter 28) or if the user replies "L" when notified of how many bulletins exist. This file should contain a list of the bulletins (i.e. 1-99) and a brief one-line description of the contents of each (e.g. "New Release of RBBS-PC"). Parameter 62 allows a SYSOP to have from 0 to 99 "bulletins." If there are 0 bulletins a user is notified that there are no bulletins. Bulletins should be brief, informative, and timely. I personally think that there should be very few bulletins and that they should be changed often if users are to be enticed to look at them. If you make bulletins optional (parameter 28) RBBS-PC will automatically bring new ones to the attention of each caller when they log on. Parameter 63 provides the SYSOP with the flexibility to make the prefix of the bulletins anything he wants (i.e. BULLET). To this is added the number (e.g. BULLET7 for bulletin number 7) and the disk drive designated in parameter 61 is searched for the bulletin number requested when some asks to see a bulletin. If the file is not found, the user is so informed. If a "graphics" equivalent is found and the user requested graphics, the graphics version of the bulletin is displayed - BULLET7G (i.e. contains characters with values of 0 through 255) or BULLET7C (i. e. contains characters with values of 0 through 128 which, hopefully, are ANSI screen commands) RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 81 of 232 Parameter 64 indicates the disk drive and path on which RBBS-PC is to search for to find RBBS-PC's on-line "help" files whenever a user asks for help within a specific subsystem. This is where the help files should be stored. There are some specific help files used by RBBS-PC whose name is simply a help prefix plus a number. The SYSOP may elect to call the prefix something other than the default of "HELP0". Parameter 65 allows the SYSOP to pick up to a seven-character prefix to which the numbers will be appended. This file name is what RBBS-PC will look for on the drive specified in parameter 64 when a user asks for help on-line. As with "bulletins", if a "graphics" equivalent is found and the user has signed on N/8/1 and requested graphics, the graphics version of the help file is displayed (i.e. HELP07G). RBBS-PC identifies help for a particular command by the letter of the section and the letter of the command, plus an extension for the help files. The extension "HLP" is the default but parameter 66 lets the SYSOP set this to whatever desired. Parameter 67 is the name of the file that is displayed to a caller when the caller is requested to categorize a file that has been uploaded. RBBS- PC' File Management System can be configured to minimize the activities of the SYSOP by allowing users to categorize the files that are uploaded. This file should list the names of the categories that an uploader can select. It should be stored on the same drive and path as the other help files. The category selected will be validated to make sure that it is in the list in DIR.CAT or that a valid category file with that name exists. The appropriate category code will be written out to the shared FMS directory if the FMS system is active. If the FMS system is not being used or a separate .DIR file with the category name exists (e.g. GAMES.DIR), the description of the entry for the upload will be appended to the .DIR file. Parameter 68 allows the SYSOP to select any name for the text file that new users see when they first log on and before they "register" themselves in RBBS-PC's USERS file. A user sees it once and only once during his first session. It can contain anything you want it to, but a brief explanation of your Board's purpose, "rules", etc. might be appropriate. Parameter 69 allows the SYSOP to select any name for the text file that each user sees EVERY time AFTER they log on. Keep it brief! RBBS-PC will look for a "graphics" equivalent if the user qualifies for graphic displays (i.e. it will display the file HELLOG or HELLOC in lieu of HELLO). The default name for this file is WELCOME. Parameter 70, parameter 71, parameter 72, parameter 73, parameter 74, and parameter 75 focus on the text files that RBBS-PC displays to novices as "menus." Menu files shown to novices tend to be frequently accessed. Systems that do not have disk caching should consider putting menus in a RAM disk in order to cut down on the wear and tear of your disk drives. Parameter 70 allows any valid name to be given to the text file containing the commands allowed those with SYSOP privileges. RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 82 of 232 Parameter 71 allows the SYSOP to specify the name of the text file containing the menu of commands available to those in the main "messages" subsystem. Parameter 72 allows the name of the text file containing the menu of commands available to those in the "files" subsystem to be any valid name. Parameter 73 allows the name of the text file containing the menu of commands available to those in the "utilities" subsystem to be any valid name. Parameter 74 is the name of the text file listing the names of the conferences that are available. Conference names must be seven-characters or less, in all caps, and cannot have any character to the left or right of the name except possibly a space. The SYSOP must already have pre- formatted the messages and users files associated with the conferences (see section 18). Parameter 75 allows the SYSOP to name the text file containing the list of the questionnaires, surveys, or forms which callers can fill out and answer on-line. The scripting support built into RBBS-PC allows the SYSOP to construct a series of questions to be presented to the caller and save the answers. Questionnaire names must be eight characters or less, in all caps, and cannot have any character to the left or right of the name except possibly a space. Of course, the actual file name for the script has an extension of ".DEF". Thus, a questionnaire called SURVEY would appear in the text file identified in Parameter 75 as SURVEY, preceded and followed by at least one blank character, and exist as a file named SURVEY.DEF. Parameter 76 allows the SYSOP to specify the drive and path where the optional questionnaires will be located. If the file specified in parameter 77 exists, RBBS-PC will assume that the SYSOP is using RBBS-PC's "Programmable User Interface" (PUI) -- see section 8 for a fuller description of RBBS-PC's PUI. Parameter 78 allows the SYSOP to elect to have RBBS-PC have full page control. By this it is meant that all displays will be interrupted after the number of lines set by the user for his "page length" have been written to the user's screen. This, on occasion, may mean that menus will pause in the middle with a prompt waiting for the user to hit enter. The advantage of allowing this to happens means that no information on the user's screen will "scroll off" the top of the screen. The disadvantage is that menus may not be viewed in their entirety. Replying "NO" to this parameter means that menus will be fully displayed on a single screen, but some information that preceded the menus may scroll off the top of the screen. Parameter 79 and parameter 80 allow the drive, path name, and extension to be used for RBBS-PC "macros". See section 8.8 for a fuller description of RBBS-PC extensive "macro" capabilities. RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 83 of 232 11.5 Parameters for RBBS-PC System Files (part 2) ------------------------------------------------- Parameter 81 is the name of the text file (TRASHCAN) listing names that the SYSOP considers inappropriate. This file is used when a new user signs on. The new users first and last name are each individually checked against the names in this file. The format of this file is as follows: <name>, An example of such a file would be: BITE, BYTE, DOC, DOCTOR, DEATH, GLADIATOR, KILLER, MAN, THE, The comma is optional after each name. However, it does help in delineating exactly what character strings are being searched for and compared against (some text editors may add extraneous and non-visible characters to a line). All names should be UPPER CASE! If you create the file using IBM's standard DOS text editor, EDLIN, each line may end with either a comma or a carriage return. If you create the file using COPY CON, each line should end with a carriage return (i.e. the "enter" key). The last line (when using COPY CON) should end with a Control Z, F6, and then carriage return. BASIC will treat either a comma or a carriage return as a field delimiter. You need a field delimiter following each of the names. If the above file existed, any new user who logged and used the following names would be denied access: Byte Killer Kilo Man Doctor Death PC Doctor Parameter 82 lets the SYSOP force a questionnaire to be answered by all callers, old and new, exactly once. RBBS-PC records in the users record when the required questionnaire is answered so that it will not ask the caller again. Parameter 186 lets the SYSOP reset the flag back to off for all users. This should be done when the SYSOP wants to install a new required questionnaire to be used to survey all callers. If no questionnaire is required, this parameter can be specified as NONE. Parameter 83 allows the SYSOP to specify the name of the file that will be displayed as soon as carrier is detected and BEFORE a user can log on. It is displayed immediately after the name of the RBBS-PC is shown (see parameter 12). SYSOPs should use "PRELOG" to convey such information as whether real names are required, 300 baud users will automatically be RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 84 of 232 denied access, etc. RBBS-PC provides a sophisticated, script-driven capability that allows a SYSOP to ask new users questions or questions of all users when they say G>oodbye. Parameter 84 allows the SYSOP to specify the file name of the script of questions to ask new users. Parameter 85 allows the SYSOP to specify the file name of the script of questions (if any) to ask users when they say G>oodbye. The SYSOP can set up the script so as to raise or lower a new users security level based on the answers. Contained within these scripts is the file name to which the answers are to be written. Parameter 86 allows the SYSOP to specify the file name for the file used by RBBS-PC to hold the messages on the bulletin board. This file can NOT have an extension because RBBS-PC appends the extension ".BAK" to the file name when "packing" the messages file. NOTE: Read section 19 if you want to include the main message file in the scan for conference mail waiting. RBBS-PC keeps a profile of each user who logs on in a "user record" (see Appendix A for a layout of this record). Parameter 87 allows the SYSOP to specify the file name for this file. This file can NOT have an extension because RBBS-PC appends the extension ".BAK" to the file name when "packing" the users file. Instead of leaving a "message", a user may leave a comment for the SYSOP that is readable only by the SYSOP. Parameter 88 allows the SYSOP to specify the fully qualified name for the file used by RBBS-PC to store users' comments. Parameter 89 allows the SYSOP to have comments recorded as private messages to him in the main messages file providing there is any room. This allows replies to comments to be done much more easily. RBBS-PC maintains a log of user activity on a "callers" file. It contains information on the date, time, communications parameters of who logged on; what they uploaded or downloaded; and any security violations or errors that were generated. Parameter 90 allows the SYSOP to specify the fully qualified name for the file that RBBS-PC uses for this log. If parameter 91 is selected, additional items of information are included in the CALLERS file: 1) "Connect not completed" 9) "Left comment at time" 2) "Sleep disconnect" 10) "Logged off at time" 3) "Caller changed name/address" 11) "Carrier dropped at time" 4) "Newuser" 12) "Message # xxxx left at" 5) "Bulletin x read" 13) "Read Messages ..." 6) "SYSOP initiated Chat" 14) "Answered questionnaire xxx" 7) "Entered Conference/Subboard x" 15) "Killed msg # xxxx" 8) "Time limit exceeded" RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 85 of 232 It should be remembered that for each occurrence of the above, the CALLERS file will increase by 64 bytes. Unless you either have a hard disk or are willing to frequently maintain your system in order to leave enough free space on the disk drives for new files, this option should NOT be activated. Parameter 92 has not been implemented in RBBS-PC. Parameter 93 allows the file name to be specified for the file containing the information on the conferences that are to be scanned for mail waiting when a user logs on. The format of this file and the flexibility it affords the RBBS-PC SYSOP is described more fully in section 19. 11.6 Parameters for RBBS-PC "Doors" ----------------------------------- Parameter 101 allows the SYSOP to enable RBBS-PC to exit and return to the system (i.e. DOS). You will also be asked if you will be running "doors" with MultiLink. If you reply yes, you may choose what type of terminal MultiLink is to assume the user is using when MultiLink receives control from RBBS-PC. See the MultiLink manual for the various terminal types. If you choose terminal type zero, MultiLink will not be given control of the communications port when RBBS-PC exits to the "door." Use this if your application is coded to control the communications port. The batch file out of which RBBS-PC is invoked should then check to see if a "door" is to be invoked. A "door" is simply a batch file that the SYSOP has created which RBBS-PC users are allowed to exit to and which will then take control of the remote users communication port. Parameter 102 allows the SYSOP to specify the fully qualified file name of the menu that lists the names of the "doors" available to users. RBBS-PC checks this file to verify that the name of the door that the user requested is in the doors menu (see section 15). A door name in the menu must have 8 or fewer characters, be in all caps, and the only character that can occur immediately before and after the name is a space. Parameter 103 allows the SYSOP to specify the fully qualified file name of the file that RBBS-PC is to use when dynamically building the .BAT file that invokes the "door" selected by the user. The batch file that invokes RBBS-PC must contain an "IF" to check if this file exist whenever RBBS-PC terminates and (if it exists) to execute it (see section 14). This is also the same file name that is used when the SYSOP exits to DOS. When a door finishes RBBS-PC is re-invoked. Parameter 104 allows the SYSOP to specify the fully qualified file name of the .BAT file that should be used to re-invoke RBBS-PC (see section 14 and section 15). This is also the same file name that is used when the SYSOP returns from exiting to DOS. Whenever a remote user exits to a "door" or to DOS (via the remote SYSOP function 7), RBBS-PC needs to know where to find COMMAND.COM. In a network environment with several PC's the COMMAND.COM's may be different for each PC. Parameter 105 allows the SYSOP to specify for the each copy of RBBS-PC a disk drive and path on which to find the COMMAND.COM appropriate for that copy of RBBS-PC. RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 86 of 232 Parameter 106 allows the SYSOP to elect how I/O is redirected to the communications port when dropping to DOS as a remote SYSOP (command "7"). When configuring RBBS-PC you may select to have the I/O redirected either via the standard DOS "Change Console Command" (CTTY), or having DOS redirect standard I/O (">" or "<"). This parameter allows you to specify if the redirected output is to be handled by a special device named in CONFIG.SYS. If you don't elect to use a special device driver, RBBS-PC will redirect the output directly to the communications port by building the command "CTTY COMx" or ">COMx and <COMx" , where "x" is based on the communications port the node was configured for. If you specify the name of a device driver, it should also be in the CONFIG.SYS of the system that RBBS-PC is running on. As an example, if you specified a device driver of GATE, RBBS-PC would build the command CTTY GATE. Parameter 107 allows the SYSOP to select how RBBS-PC is to invoke external programs. There are two ways to execute these other programs: 1. EXITing RBBS-PC and invoking the other program via a .BAT file that RBBS-PC builds dynamically, or 2. SHELLing to the other program while RBBS-PC remains in memory. EXITing RBBS-PC allows other BASIC programs to be run as external programs to RBBS-PC, conserves memory, and allows all of RBBS-PC's features to be active in computers with only 320K of memory. The "price" that is paid is that upon returning from the externally called program RBBS-PC's .EXE file must be reloaded into memory. SHELLing prohibits other BASIC programs to be run as external programs to RBBS-PC, consumes memory because RBBS-PC remains in memory when the other program is running, and requires 386K of memory (under DOS 3.2) to activate all of RBBS-PC's features. However, SHELLing does eliminate the need to reload the RBBS-PC.EXE file each time. Parameter 108 specifies the name of a program (i.e. an .EXE or .COM file) that control is to temporarily to be passed through when the caller is determined to be a new user. When this .EXE or .COM file finishes and RBBS-PC is re-invoked, the RBBS-PC logon sequence will continue uninterrupted from the point at which the caller was determined to be a new user. This feature is intended for those who feel the need to perform an extensive verification of new user's that is not met by RBBS-PC's built in scripting capability or automatic subscription functions. This feature allows those SYSOPs who have the need to reference membership lists, verify political affiliation, interrogate blood type, or "qualify" new users via whatever criteria seems expedient to their needs/purposes in any way they wish simply by writing a program external to RBBS-PC. 11.7 Parameters for RBBS-PC's Security (part 1) ----------------------------------------------- Parameter 121 is the first and last name alias (i.e. pseudonym) that the SYSOP will use when logging on remotely. It is this alias name that causes RBBS-PC to recognize the remote caller as the SYSOP and not simply a user with a security level equal to that of the SYSOP. This should be a first and last name combination that is not likely to be selected by other callers. If you want to eliminate anyone from logging on as the SYSOP, RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 87 of 232 you can simply reply with a "null" (i.e. a carriage return) for the first and last name for parameter 121. The ESC key is used to log on in local SYSOP mode. Parameter 122 can be set so that the pseudonym specified for parameter 121 is required to be entered from the local keyboard of the personal computer on which RBBS-PC is running when the escape key (Esc) is pressed. If you enter YES, no password is required. Parameter 123 specifies the minimum security level users need in order to log onto RBBS-PC and parameter 124 specifies the security level assigned to new users. If the security level assigned new users is less than the minimum security level to log on, no new users can logon on. This means that no new users are allowed and access is limited only to pre-registered users. Since one of RBBS-PC's two objectives is to facilitate the exchange of information, every RBBS-PC SYSOP is urged to not entirely deny new users access. The chapters on RBBS-PC's extensive security features and subscription and time management system detail the ways in which a SYSOP can control access to his RBBS-PC without having to deny access to new users -- chapters 16 and 10, respectively. Parameter 125 specifies the minimum security level a user must have in order to be considered a SYSOP . Even if a user has a high enough security level to see the SYSOP menu and execute some or all of the SYSOP commands, the user will not be treated as a SYSOP (i.e. allowed to see the files upload/download when viewing the CALLERS file) unless the users security level is equal to or greater than that specified by this parameter. Parameter 126 prevents the SYSOP menu from being displayed (even if the user has a security level of a SYSOP as specified in parameter 125) unless the user is also at this security level. Parameter 127 is the minimum security level a user must have to leave an extended (i.e. multiple line description) of a file that was uploaded. See parameter 40 for the maximum number of lines that an extended description will be allowed under the single FMS environment. Parameter 128 allows a maximum number of security violations (i.e. attempts to download protected files) before the user is logged off and locked out. Parameter 129, parameter 130, parameter 131, parameter 132, and parameter 133 allow the SYSOP to set up the security levels required to issue the commands in the SYSOP, Main Menu, File Subsystem, Utilities Subsystem (respectively), and global commands. All the commands in each area can be given the same security level or, optionally, a specific command can be given a unique security level. Parameter 134 allows the SYSOP to specify the maximum number of times users can change their passwords in a given session. This prevents a caller from "fishing" for special passwords. Parameter 135 is the minimum security level required in order for users to change temporarily their security or time on the system via privileged RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 88 of 232 group passwords. If users do not have the minimum security level to temporarily change their password, ALL password changes that they make will be permanent -- even if the password they select is in the temporary password file named in parameter 146 of CONFIG! Parameter 136 allows the SYSOP to specify a security level that has the privilege of overwriting files (i.e. files that already exist) when uploading. When the SYSOP "purges" the USERS file, all users who have not signed on within the number of months specified in parameter 11 are deleted from the file with the exception of those who have been "locked out" and those whose security level is equal to or greater than that specified in parameter 137. Parameter 138 allows the SYSOP to specify the security level required to read new PRIVATE messages. Only those with this security level or higher can read new private messages -- even if they have been addressed to them. By setting this value higher than any other user than that of the SYSOP, the SYSOP can then review all new private messages before allowing them to be seen by the addressee. After reviewing these messages, the SYSOP can change the security level so that the message can be seen by the sender and the addressee. Parameter 139 allows the SYSOP to specify the security level required to read new PUBLIC messages. Only those with this security level or higher can read new public messages. By setting this value higher than any other user than the SYSOP, the SYSOP can then review all new public messages before allowing them to be seen. After reviewing these messages, the SYSOP can change the security level so that the message can be seen. Parameter 140 specifies the minimum security level that is able to change the security level of a message. 11.8 Parameters for RBBS-PC's Security (part 2) ----------------------------------------------- Parameter 141 is not implemented in RBBS-PC. Parameter 142 allows the SYSOP to specify the drive and path where the "personal directory" and files it contains are located. If a file listed in the directory is not found here, the download drives will then be searched, so it is not necessary to have a copy of a file here in order to be personally downloadable. However, the download directory must be here. Parameter 142 allows the directory and/or files that are personally downloadable not to be accessible through the normal download, if desired. The "personal directory" is utilized by the P)ersonal download command in the files section of RBBS-PC. It differs from D)ownload in that (a) only files listed in the directory can be downloaded versus any file that exists, (b) the time to download is not checked against the time remaining, so that the file can be downloaded regardless of how little session time remains, (c) the files downloadable can be constrained to match any field in the user's record (e.g. limited by caller's name RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 89 of 232 so that file is addressed specifically to the caller), (d) the download can be constrained by security level. Parameter 143 allows the SYSOP to provide the name of the "personal directory" -- the default name is "PRIV". If no extension is specified, ".DEF" will be used. The personal directory has a different format from the other directory files. It has a one-character field after the file description used to mark whether file has been downloaded. This is followed by the field that matches the user record (or has a security level if the first character of the field is blank). Parameter 144 is a way of specifying the default protocol to be used when downloading personal files using the "P" command in the file subsystem. If no protocol is specified, the "P" command behaves exactly same as the D)ownload command. If a protocol is specified, it will be used unless overridden by the command line (i.e. "P;test;y"). Parameter 145 specifies the name of the file that contains a list of file names that CANNOT BE DOWNLOADED (even if they are on the disks that are available for downloading) unless the user supplies a password and/or is at a specific security level. If you want to have no file security at all, just put no file names in this file. If you include a password with a file name all users (including one with SYSOP privileges) must be able to give the password in order to download the file. For a more detailed description of this file and how it works, see the section entitled "How to Implement the Security for Download Files." Parameter 146 specifies the file name which contains the privileged group passwords that allow users to change temporarily their security, time on the system, etc. -- if the SYSOP has set it up that way. Callers shift to a group password by changing passwords. If the password they select is found in the file containing the privileged passwords, their private logon password is unchanged and they receive the security level and/or time limit associated with the group password. If you have no group passwords, just put nothing in this file. For a more detailed description of this file and how it works, see the section entitled "How to Implement the Password File." Parameter 147 provides the SYSOP with the mechanism to allow users to download multiple files using the ASCII protocol (i.e. no error checking) without any pausing or messages between files. This is particular useful if the SYSOP wants users to download to a continuous feed printer. Parameter 148 specifies the minimum security a user must have in order to be able to "categorize" uploads when the SYSOP is using the File Management System (FMS). Not all callers who upload files may categorize them in the way that the SYSOP wants. Parameter 149 controls who can view new uploads based on security level. If the upload directory is not also the FMS directory, it is only viewable by those who have a sufficient security level. If the upload directory is the FMS directory, the entries with the default categories will be viewable only if a caller has a security level equal to or greater than that specified in parameter 149 (all other categories are viewable). RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 90 of 232 Parameter 150 specifies the security level of those users who will not be shown the "epilogue" questionnaire. Typically the "epilogue" questionnaire asks users questions or invites them to register. Once they have done so, the SYSOP can have their security increased to this value either automatically (i.e. via the questionnaire's script) or manually such that the users no longer see the "epilogue" when they sign off. Parameter 151 is the security level required to automatically add a user to a SEMI-PRIVATE "conference". This parameter can only be activated when CONFIG is in "conference maintenance" mode (see parameter 167). Each message file has a security level associated with it which is the MINIMUM SECURITY for a user to join it if the user is not in that conference's USERS file. Callers with the minimum security level specified in parameter 151 are automatically added to the USERS file associated with that conference if they are not there. RBBS-PC's "auto-add" security feature permits SEMI-PRIVATE conferences, that are open to callers with a certain security level. The "auto-add" capabilities of RBBS-PC makes it possible for SYSOPs to have non-public conferences without having to add each desired caller to the user's file. A public conference is one whose "auto add" security level is no higher than the default security and whose USERS file is the same as the main message base's. This has the advantage of saving disk space (i.e. there is only a single USERS file) but the disadvantage of not remembering the last message read by the user in each conference. A totally PRIVATE conference is one that is limited to persons already in the USERS file associated with that conference and is created by making the "auto add" security level higher than any caller's security. A SEMI-PRIVATE conference is one that has it's own USERS and welcome file and whose "auto add" security level is set at an intermediate level that some callers have and some do not. As an example if a conference is to be totally public but the user's last message read, preferences, and security level in the conference to be remembered, 1. set the security level required to automatically add a user to the conference equal to the CONFIG utility parameter 124 (the default security level for new callers), and 2. create a user's file for the conference. All callers can join, and each user is automatically added to the conferences user file as they join the conference. If you want a conference to be SEMI-PRIVATE set the security level to be "auto add"ed to the conference higher than the default security level for your system and only those users who have the security level specified in parameter 151 can join the conference. RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 91 of 232 Parameter 152 is the minimum security level for a caller to "turbo logon". It only applies to callers that have called your RBBS-PC system at least once. It can be used to bypass everything when a user logs on (bulletins, welcomes, etc.) and go directly to the either the main RBBS-PC menu or directly to a conference. It only can be utilized when doing a single line log on and by following your password with an exclamation point. The "single line" logon has the format: first name;last name;password;!conference name As an example, a user named "Jon Smith" who called back for the second time and had a password of "swift" who had been assigned a security level that permitted "turbo logon" privileges who wanted to go directly to the conference "RBBS-PC" could log on with the following sequence: jon;smith;swift;!rbbs-pc Parameter 153 is the minimum security required by a caller to add a directory entry for an existing file. Typically this is restricted to the SYSOP only. Parameter 154 is the name of the help file that is automatically shown (if the file exists) to a caller whenever the caller incurs a security violation. It is an ideal candidate for using RBBS-PC's personalized "smart" text file capabilities as described in section 8.9. Parameter 155 allows the SYSOP to deny callers access to two of RBBS-PC's "premium features -- DOORS and file downloading (either or both), for a specific period of time. One of the two purposes of RBBS-PC is to foster the free exchange of information. Many SYSOPs would like to encourage new callers to read bulletins and look at messages when they initially logon. One approach is to simply restrict new users from all of the other RBBS-PC features using RBBS-PC's extensive security system. RBBS-PC provides an intermediate solution by allowing a SYSOP to require a user to be on-line for a specific amount of time within a session before DOORS or file DOWNLOADS, premium features, are available to a caller. This feature is implemented by both activating CONFIG parameter 155 and setting up the PASSWRDS file appropriately, see section 16.3. For each level in the PASSWRDS file, a parameter specifies how many SECONDS the caller must have used before the premium features are available. If a caller tries to use a locked feature before the time has elapsed, the caller will be given a message and denied access. This is *NOT* recorded as a security violation. See section 16.3 for a more detailed description of how to implement this feature in the PASSWRDS file. The file TIMELOCK.HLP should be placed with the other RBBS-PC HELP files. This file (if found) will be shown to a user who is locked out of a command. If the TIMELOCK.HLP file is not available, the caller will be given a "canned" message: "Sorry, (name), try that function later." The example TIMELOCK.HLP uses SMART TEXT. If SMART TEXT is not implemented RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 92 of 232 with control code (123), the file TIMELOCK.HLP should be modified as appropriate. 11.9 Parameters for Multiple RBBS-PC's/Conferences -------------------------------------------------- RBBS-PC allows multiple RBBS-PC's to run in the same environment/network and share many of the same files. If you ever plan to do this or if you are going to do this, set this number to the MAXIMUM number you ever envision running. Up to 36 RBBS-PC's can share the same files. Different environments have different maximum number of nodes that they can effectively support. Parameter 161 allows you to specify the maximum number of RBBS-PC's that the MESSAGES file should be initialized for. Parameter 162 allows the SYSOP to designate the type of environment that multiple copies of RBBS-PC will be sharing files in. This is necessary so that RBBS-PC can use the mechanism that is appropriate to the specific environment when sharing files. RBBS-PC currently can handle the following environments for multiple RBBS-PC's: 1. MultiLink (The Software Link, Inc.) 2. OmniNet (Corvus) 3. PC-Net (Orchid) 4. DESQview (Quarterdeck Office Systems) 5. 10 Net (Fox Research using 3COM interface) 6. IBM's NETBIOS NOTE: Many manufacturers utilize Orchid's network conventions. As an example, AST and Alloy are both vendor's whose "network" is .EXE file- compatible with Orchid's. If you have a network of PC's, check with the vendor to see how compatible their network is with those supported by RBBS- PC. Some local area network environments are not designed to have applications constantly branch back to the beginning and re-open already open files. If you are in this environment or simply want to run external programs after a user logs off or RBBS-PC recycles, parameter 163 allows you to elect to do this. If you specify "internal", RBBS-PC will function as it currently does and branch back to its beginning. If you specify "system", RBBS-PC will exit to DOS and (if you are running RBBS-PC out of a .BAT file) you can then automatically invoke any other "housekeeping" programs you want before re-invoking RBBS-PC. It should be noted that this will add a considerably delay to RBBS-PC's recycling time as RBBS-PC will have to reloaded back into memory every time it recycles. Like the MESSAGES file, the USERS file must also be static in length for RBBS-PC. Parameter 164 allows the SYSOP to set the size of the USERS file. RBBS-PC automatically keeps track of the records available for use in this file and does the necessary "housekeeping." To do this RBBS-PC requires the USERS file size (i.e. the number of records in it) to be a power of 2. When the USERS file get full (i.e. all its records are used up) and the SYSOP neither "packs" it nor increases the size of the file, no new users will be able to be added to the users until one of these two events occurs. Parameter 291 lets new users get on even if the users file is full. RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 93 of 232 RBBS-PC requires that the "Messages" file be static in length. It automatically keeps track of the next record available and does the necessary housekeeping to maintain the integrity of the file. Parameter 165 allows the SYSOP to set the size of this file. CONFIG.BAS will automatically determine what size the current file is and will reformat a pre-CPC12-3A MESSAGES file if it finds one. If you do not increase the size of your existing MESSAGES file, no one will be able to leave any new messages. Similarly, when the MESSAGES file get full (i.e. all its records are used up) and the SYSOP neither "packs" it nor increases the size of the file, no one will be able to leave a message until one of these two events occurs. The minimum size of the MESSAGES file is equal to 1 (The "checkpoint" record) plus the maximum number of concurrent RBBS-PC's ("node" records) plus the maximum number of messages allowed multiplied by 5 (each messages is assumed to average five 128-byte records) Therefore, if parameter 161 of CONFIG where 12 and parameter 165 of CONFIG where 50, the minimum number of records that could be specified for parameter 125 would be 1 (The "checkpoint record) + 12 (The number of "node" records) +250 (50 messages x 5 128-byte records each) ---- 263 records for the MESSAGES file Parameter 166 lets you set the maximum number of messages that the SYSOP will allow on the system at any one time. The number will have to be based on the size of the average message on your bulletin board. Most messages require about 600 bytes on the average. The absolute upper limit on the number of messages is 999. If you specify 250 messages, you can expect that the MESSAGES file will be formatted to more than 160K in size. Parameter 167 allows "conference" files to be maintained. A "conference" consists of a message file and, if a "private" or "semi-private" conference, a corresponding users file. The name of the conference can be anything that the SYSOP selects but can not be longer than 7 characters. The message file's name for a conference consists of the conference name plus the characters "M.DEF". The user file's name associated with "private" conferences consists of the conference name plus the characters "U.DEF". Parameter 167 allows the SYSOP to create, expand, or contract either or both of the files associated with a "conference." This occurs ONLY when the SYSOP "ENDs" the CONFIG session by pressing the key marked END. Parameter 167 allows the SYSOP to perform all the utility functions on page 10 of CONFIG on the conference that was named/selected with parameter 167. To make a "private" conference "semi-private", see the discussion under parameter 151. For a further discussion of "conferences" see sections 18 and 19. RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 94 of 232 11.10 RBBS-PC SYSOP Utilities ----------------------------- The message file contains all messages for the RBBS-PC system. As messages are killed they are only flagged as inactive. Parameter 181 should be used periodically to recover the space occupied by the killed messages. After completion, only the text of active messages will be present and the old file will remain on the system with the qualifier of ".OLD". Also, you will need enough free disk space for a second copy of the messages file (with a qualifier of ".BAK") when packing a message file or the packing cannot be performed. If enough space is not found the packing will terminate abnormally and the message file will be recovered. Parameter 182 removes deleted users and users who have not been on the system within the number of months specified using parameter 16 in CONFIG. You should have enough free disk space for a second copy of the users file (with a qualifier of ".BAK") or the rebuilding will terminate abnormally (the users file will be restored). It is important to note that beginning with CPC12-5A, users files are no longer a random file that is accessed sequentially but now is a random file that is accessed directly. When a user logs on to RBBS-PC or joins a "conference", RBBS-PC "hashes" the users name to find the users record directly. That is why every users file's size is a power of 2 (i.e. 256, 1024, etc.). This allows users to log on much more quickly to RBBS-PC's that have a very large number of users. Parameter 183 will display the message headers of all messages, active and killed, that are present in the message file. This is left over from one of the many "debugging" stages of RBBS-PC prior to CPC09. Following the policy of making all changes "additive", this function has been retained. It may help some SYSOPs recover from disk hardware failures. Parameter 184 permits messages to be renumbered sequentially starting from a specified message using whatever starting number you wish. Please note that there is not much error checking to be sure that the new numbers do not duplicate those of lower numbered active messages. When complete, the next message to be created will be the next higher number from the resequence. Unpredictable results will occur if a SYSOP creates messages with duplicate numbers! Parameter 185 goes through the current message file and reconstructs the chains that link the messages together. Message files that have "blank" messages or abbreviated messages (i.e. some lines of text are missing) can be repaired with this facility. Parameter 186 allows the SYSOP to require all users (old and new) to answer the required questionnaire whose name was specified in parameter 82. Parameter 187 allows the SYSOP to determine whether the format of the RBBS- PC directory of files being used by the RBBS-PC File Management System (FMS) conform to the exact fixed format required by the FMS (in case the text editor used by the SYSOP to edit the file inserted tabs or shorten lines that had trailing blanks at the end of them). RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 95 of 232 Parameter 188 allows the SYSOP to determine whether the format of the personal downloads directory is in the proper format for a single FMS. Parameter 189 is a utility that will guide a new SYSOP, sequentially, through the parameters that would normally have to be changed when setting up a new RBBS-PC. Parameter 190 is a utility that will guide a SYSOP, sequentially, through the parameters that are new and/or changed for the current release of RBBS- PC. Parameter 191 is a utility that will turn the "printer enabled" flag off in all the node records. This is useful if somehow the printer is accidentally enabled when no printer is available because the code generated by the BASIC compiler doesn't recover from this condition. Parameter 192 allows the SYSOP to select how "highlighting" of text will be treated. This prevents users who have not elected to have color graphics from seeing meaningless data imbedded in the displayed text. Putting in nothing disables color prompts and highlighting of search strings. For a more complete explanation of RBBS-PC's display of colors to callers in text files see section 8.10. 11.11 Parameters for RBBS-PC's File Management System ----------------------------------------------------- Parameter 201 specifies the letter of the single drive available to this copy of RBBS-PC to which uploaded files can be written. When a file is uploaded, the file specified by CONFIG parameter 202 will be automatically appended with the file name, file size, date of upload, and short description as specified by the user. Parameter 202 of the CONFIG program asks for the name of the text file to be used as an RBBS-PC "directory" of files into which the file name, file size, and file description of uploaded files can be recorded. The default name is 99.DIR and it must be on the drive/path specified in parameter 203. Parameter 203 specifies the drive/path were the upload directory is to be found. Parameter 204 specifies the letters of the drives from which files can be downloaded. The order in which they are specified is the order in which the drives will be searched. If the order is BAC, then drive B will be searched first for the file, then drive A, and finally drive C. While there can be duplicate files on each of the drives, the first file found will be the one downloaded to the user. Parameter 205 allows the SYSOP to indicate that DOS subdirectories are to be used by allowing the number of DOS subdirectories to be used for downloading to be specified (0 to 9999). This number is equal to the number of DOS subdirectories to be used for uploading (0 or 1) plus the number of DOS subdirectories to be used for downloading. RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 96 of 232 Parameter 206 allows the SYSOP to indicate the DOS subdirectory to which uploads are to be written. RBBS-PC will prepend the upload disk drive to it (see parameter 201) and append the upload file name after it when uploads are written to disk. Parameter 207 allows the SYSOP to indicate that DOS subdirectories are to be used when searching for files on downloading. A valid download drive followed by a colon, a reverse backslash, and the subdirectory name that is to be searched must be entered. If the root directory is also to be searched, just enter a valid download drive followed by a colon. Each download disk drive is searched for only those subdirectories that were specified as existing on that specific drive. If two download DOS subdirectories are specified (A:\TEST1 and B:\TEST2) and two download disk drives for parameter 204 (A and B), the search for a download file will be in the following order: A:\TEST1\filename B:\TEST2\filename It is possible to have the same subdirectory name on different download drives. Each would have to be individually specified (A:\GAMES and B:\GAMES If they where, the search for a download file would be as follows: A:\GAMES\filename B:\GAMES\filename Parameter 208 is only functional if you have responded "Yes" to either parameter 206 or parameter 207. This parameter allows the SYSOP to list, change, add, or delete the DOS subdirectories to be used for either uploading (parameter 206) or downloading (parameter 207). CONFIG does NOT actually create or delete such DOS subdirectories -- that's up to the SYSOP to do using the standard DOS commands. Parameter 208 simply allows the SYSOP to identify which DOS subdirectories will (or may) exist when RBBS-PC is running. Parameter 209 allows the SYSOP to specify the extension that RBBS-PC's "directories" of files are to have. See section 13 for a description of RBBS-PC's "directories" of files.-- they have no relation to DOS 2.x and above subdirectories! Most SYSOPs categorize the files that are available for downloading into general groups (games, utilities, etc.). The default is "DIR". Parameter 210 specifies the alternative extension to be used for "directory" files. The main use for an "alternate" extension is to allow "sub-boards" to share directories using the main extension (parameter 209), but also have some directories unique to the "sub-board" that are not shared with others. The name of the directory of directories is specified in parameter 211. This allows sub-boards with the same extension to have a different directories of directories. The main RBBS-PC system might have a directory of directories named MAIN.DIR where parameter 211 was "MAIN" and parameter 209 was "DIR". A sub-board might have a directory of directories named RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 97 of 232 BETA.DIR where parameter 211 was "BETA" and parameter 209 was "DIR". Parameter 212 allows the SYSOP to exclude the primary directory (DIR.DIR) from the search done by the New command. If you have multiple directories (i.e. RBBS.DIR through BASIC.DIR), any dates in the primary directory would not be of files. The "New" command (as in "What new files have been put on the download directories since I was last on?") search each line of each file whose extension is DIR for a date field. Since the first level directory is normally a listing of the other directories and their general subject areas, it is advisable to omit the first level directory from the "New" command. Descriptions of files uploaded are always appended to the upload directory. Parameter 213 allows the description to be appended to another file. This could be, for example, a list of all files on the system, or the basis for a bulletin reviewing the uploads. Parameter 214 is how the SYSOP declares that there is a shared, single FMS directory. Leave it blank if there is none. Section 13 discusses in detail the advantages of using this directory, which has a different structure from other directory files. This file must be in the drive/path for directories. Users who upload can classify uploads into a category if their security is at least as high as the level specified in parameter 148. This option can save the SYSOP considerable time. If the uploader cannot classify the upload, it goes only to the upload directory and uses the default category code if written to the FMS directory. If you do NOT want users to categorize the files that they upload, independent of whether or not you are using FMS, simply set the CONFIG parameter 148 to a security level higher than any user can obtain. If the uploader cannot classify the upload, it goes only to the upload directory and uses the default category code if written to the FMS directory. If you DO want users to categorize the files that they upload you must follow these four steps: 1. Set CONFIG parameter 148 to the security level of the U>pload command. 2. Create a help file to show users when they are asked to categorize an uploaded file that might look something like: Category Category Description Code Name 1 Utilities General Utilities 2 Games Games 3 RBBS-PC RBBS-PC files 4 RBBS-UTIL Utilities for RBBS-PC 3. Set CONFIG parameter 67 to the name of the file that you created for step 2 RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 98 of 232 4. If, and ONLY if, you are using the FMS, create a second file in the format described in section 13.4 for parameter 217 and set parameter 217 to the name of the file created in this format. Set parameter 215 to "YES" if there are no directories other than the FMS directory. That increases the speed of RBBS-PC because it does not look for additional directories. If you do not have a shared directory or have a hybrid system with some physically distinct directory files, set this parameter to "NO". Parameter 216 is the default category code for uploads. This parameter is how uploads get classified in the FMS directory if the uploader cannot provide a classification. To make all new uploads private and viewable only by the SYSOP (until the SYSOP reviews the files and changes the classification), set the default code to "***". The default is "UC" for UnClassified. Parameter 217 is the name of the text file which tells RBBS-PC what categories are included in the shared FMS directory. The format of the file is described in section 13.5. Parameter 218 allows the SYSOP to restrict searches (either for specific strings or via the "N>ew" command by date) to a single RBBS-PC directory of files. If not restricted, all RBBS-PC file directories will be searched. Parameter 219 sets the maximum length of the description that can be given to an uploaded file. RBBS-PC can be configured so that those who upload files can provide a description of the file they upload. This description informs others what the file does and helps them decide whether they want to download the files. The maximum length of the description can be set to any value between 40 and 46. WARNING: this option will not change the length of existing directories. Parameter 220 specifies where all directory files must be put, except possibly for the upload directory. Only in this DOS directory does RBBS-PC look for RBBS-PC directory files, with the sole exception of the upload directory when the caller's security level permits the upload directory to be viewed (see parameter 149). 11.12 Communications Parameters (part 1) ---------------------------------------- Parameter # 221 requests the user to specify the communication port that RBBS-PC will use. If you specify COM0, RBBS-PC will run on a PC without using a communications port or modem and still appear to the PC user as if they were accessing RBBS-PC remotely. This "workstation" feature can allow RBBS-PC to be used in a local area network environment where each of up to 36 PC's can access the central RBBS-PC system (on the LAN server) and use RBBS-PC for electronic mail within the LAN. Alternatively this "workstation" mode can be used to teach users how to access RBBS-PC in a classroom environment without requiring telephone access. The BASIC language can only support COM1 and COM2, and when either of these are selected and you specify that you will not be using a "FOSSIL" driver, RBBS-PC will use the built-in BASIC support for remote access (i.e. via a RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 99 of 232 communications port and a modem). However, RBBS-PC will interface with "FOSSIL" drivers that support not only COM1 and COM2 but also COM3 through COM8. If you use parameter 221 to indicate that RBBS-PC is to access the communication port via a FOSSIL driver, the FOSSIL interface (FOSSCOMM.OBJ) written by Daan Van der Weide will be used. FOSSCOMM.OBJ provides access to whatever FOSSIL drivers that are installed on the PC running RBBS-PC. In a multi-tasking environment such as DESQview up to 8 copies of RBBS-PC can run simultaneously accessing COM1 to COM8, respectively, using Ray Gwinn's X00.SYS device driver. Ray can be reached via FidoNet (109/639) or the RENEX bulletin board at (703) 494-8331 or (703) 690-7950. Parameter 222 allows the SYSOP to specify the number of seconds that RBBS- PC should wait after initializing the modem with a "reset" command. Most modems require only 2 seconds, however some may require much (MUCH) longer. If the 2 second default is not sufficient consult with your modem vendor and try different settings. Parameter 223 allows the SYSOP to specify how long to wait prior to issuing a modem command. This is most useful when you have configured RBBS-PC to only issue commands between rings and want the modem to "settle down" after a ring has ended. The default setting is one second. If you find that 2400 baud calls are improperly connected at 1200 baud, increase the wait. Some modems take longer to connect at 2400 than at lower speeds. Parameter 224 specifies the number of rings to wait before answering the phone. Specifying zero rings means that the modem (not RBBS-PC!) will answer the phone as soon as it rings. If you specify the number ONE, RBBS- PC will wait for the phone to ring and then instruct the modem to answer the phone. This is the default setting and requires that the modem be capable of indicating to RBBS-PC that the phone is ringing -- either providing the "ring indicator" signal via a modem cable that has PIN 22 connected at both ends OR by sending the characters "RING" each time the phone rings. Specifying a number equal to ZERO (and not specifying "ring-back") means that RBBS-PC will initialize the modem to automatically answer the phone (independent of RBBS-PC) and RBBS-PC will simply wait for carrier detect to occur. This is NOT RECOMMENDED. However, if your non-Hayes modem simply is incapable of indicating that the phone is ringing or your modem cable does not have PIN 22 connected, this is the option you will have to elect. If this option is selected, you will be reminded that you are shooting yourself in the foot by allowing exiting to DOS remotely (either through a "door" or via the SYSOP function 7) when activating "doors" in parameter 101. This is because in this mode (the modem answering the phone and NOT RBBS-PC), if you were inadvertently disconnected while in DOS or in a "door", the next person to dial your system would be connected to wherever you were because the modem (not RBBS-PC) is answering the phone. If you specify a number greater than 2 means that RBBS-PC will either: 1. wait until the specified number of rings to answer the phone, or RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 100 of 232 2. answer the next call after the current one after the specified number of rings specified provided that the next call comes within 45 seconds after the first call stops ringing the phone. This mode is called RING-BACK. Specifying a number greater than one is useful only when a single phone line can receive both voice (i.e. callers who wish to speak with the SYSOP) and data calls (i.e. for RBBS-PC) on an unscheduled basis. In this type of environment (i.e. a random mix of voice and RBBS-PC calls), there are two ways a SYSOP can set up RBBS-PC so that RBBS-PC can automatically determine if the call is for the SYSOP or for RBBS-PC. First, the SYSOP can establish the rule with the callers that if unable to personally answer the phone, then RBBS-PC will answer the phone after it rings the number of times specified in parameter 224. Callers can let the phone ring and (if it is not answered by a person within some agreed upon number rings) know that it will be answered by RBBS-PC. This is useful to those who may have either hearing or speech problems and are unable to use the telephone conveniently for voice communications. A second approach is the more classic, "ring-back" approach. RBBS-PC can be told to NEVER answer the first call (it can ring forever!). However, should the caller WAIT A MINIMUM OF 12 SECONDS (a Hayes restriction) and call back no later than 45 seconds after the last ring of the first call, RBBS-PC will answer the call after the number of rings indicated in parameter 224 provided that the number of rings is set to between one and five. If callers want to make a voice contact, they can simply call and let the phone ring until it is answered. If you have a dedicated line for your RBBS-PC (either full-time or on a scheduled basis), parameter 224 should be set to ZERO. Parameter 225 provides the SYSOP with the capability of selecting ANY modem commands appropriate for the modem being used -- not just the default Hayes commands RBBS-PC would normally use. Before the default RBBS-PC standard Hayes commands are changed, you should thoroughly understand the modem that your are using and the modem commands, as used by RBBS-PC, that are described in section 12. Parameter 226 allows the software-based MNP to be optional within RBBS-PC. REGRETTABLY, this option can not be selected with version CPC17-1A. This is because it was not possible to resolve the linkage incompatibilities between the new compilers and the MNP library and RBBS-PC interface prior to the release of CPC17-1A. Every effort is being made to correct this particular problem. However, RBBS-PC does support MNP protocol that is hardware-based (i.e. built into the calling and answering modems). Some SYSOPs may not wish to provide their users with the choice of MNP protocol (especially if they are employed by a company that has a competing protocol). RBBS-PC's features and growth are designed to be "additive." This parameter allows each SYSOP to decide if MNP protocol is to be available for file transfers. Microcom's error-free protocol, MNP, has been available for file transfer beginning with version CPC12-4A of RBBS- PC. RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 101 of 232 Parameter 227 allows the SYSOP to tell RBBS-PC either to wait to issue commands in-between rings or to issue modem commands without waiting. Some modems cannot both handle the telephone ringing and accept modem commands simultaneously. Other modems, like the Hayes, can handle such simultaneous demands. For these later (i.e. Hayes, Promethus, Multi-Tech, etc.) this option should be set to "NO." Some 2400 baud modems (like the Hayes) MUST be opened initially at 2400 baud because when they automatically answer the phone they can only "bump down" when automatically detecting baud rate (i.e. from 2400 down to 1200 down to 300). Parameter 228 allows the SYSOP to select the baud rate at which RBBS-PC is to open the modem at initially. The SYSOP can select the number of seconds RBBS-PC will allow a user to be "idle" (i.e. not sending or receiving data) via parameter 229. Before a user is logged off, a warning message is issued. If the caller remains idle for the following 30 seconds the caller is automatically logged off. Parameter 230 allows the SYSOP to indicate if a "dumb" modem is being used (i.e. one that will answer the phone and automatically detect the caller's baud rate if it is the the modem was opened for). Selecting this means that no modem commands are written to the modem. If the SYSOP has a non-Hayes modem (i.e. one that will not recognize Hayes commands and will not return Hayes responses) that will only "auto-answer" the phone, parameter 230 allows the SYSOP to so indicate to RBBS-PC by selecting "dumb" modem. Typically this would be some communications network (i.e. TymnNet) or local area network that supplied a simple RS-232 interface. Selecting this option causes RBBS-PC to 1. Issue no Hayes commands, 2. Depend on no Hayes-like responses, 3. Control the interface with the Data Terminal Ready (DTR), 4. Assume somebody has called whenever Carrier Detect (CD) is detected, and 5. Assume that whomever calls is at the baud rate selected in CONFIG parameter 228. The Hayes 2400 baud modem has no hardware switches. It's remembered, permanent settings can be set only through software. Parameter 231 will properly initialize a Hayes 2400 modem for use with RBBS-PC. Parameter 232 is the time to wait after dropping DTR. This is used in RBBS-PC for dropping the connection after a caller logs off normally. Too short a delay will cause the modem not to re-initialize properly. The default time is 3 seconds. In order to provide the maximum flexibility (and get RBBS-PC out of the protocol writing business), RBBS-PC supports external protocol drivers via a standard interface. The external protocol driver for YMODEM, YMODEMG, IMODEM is the file QMXFER.EXE. The external protocol driver for WINDOWED XMODEM is WXMODEM.EXE. The external protocol driver for KERMIT is PCKERMIT.EXE. These protocols work only if the external drivers are available and defined in file specified by parameter 233. Also see RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 102 of 232 sections 21.1 and 22.2 on how these drivers are invoked. RBBS-PC can check right after a caller logs on whether the caller's communication program supports autodownload. Turning on parameter 234 means that RBBS-PC will always do this check. However, this check is incompatible with some terminals and communications packages, causing them to stop displaying on the local screen. If the check is passed, RBBS-PC announces that autodownload is available and asks callers if they want to use it. This check is unnecessary for autodownload to work. The caller can control whether autodownload is used with the T)oggle command in utilities. It is recommended that this option NOT be enabled. Parameter 235 allows the SYSOP to tell RBBS-PC that files ending in binary file extensions (i.e. .ARC, .EXE, .COM, .OBJ, .WKS, .BAS, or whose second letter of the extension is Q) can not be downloaded unless the user selects a non-ASCII protocol. This should eliminate some user problems before they occur. IBM's BASIC interpreter's SAVE command default is to write files in a special binary format (also referred to as 'tokenized') because they require much less disk space. Parameter 236 allows a SYSOP to use some of the "less than perfect" modems that have a tendency to "go to sleep" under rigorous usage. Setting this parameter to a non-zero value, means that RBBS-PC will re-cycle if no calls are received after the specified non-zero value number of minutes. When re-cycling RBBS-PC resets the modem -- hence "wakes it up" if it has gone to sleep. A setting of 10 minutes is recommended for busy lines and 60 minutes for less busy lines. Specifying 0 means that RBBS-PC will not re- cycle if no calls are received, but simply wait for the next caller. Parameter 237 gives the SYSOP the option of leaving the modem at the baud rate it was initially opened at rather than automatically matching the baud rate of the caller. RBBS-PC normally changes the baud rate in the RS-232 interface to match that of the callers. Some modems will match the baud rate of the incoming caller and allow the PC to continue communicating with it at the baud rate the modem was opened at (the modem buffers it down to the callers baud). Some 9600 baud modems will allow the PC that they are connected with to transfer data to them at 19,200 baud and the modem will talk to the caller at whatever the baud rate of the incoming callers modem is set at. 11.13 Communications Parameters (part 2) ---------------------------------------- Some of the less sophisticated communications packages automatically switch back to their original communications parameters for parity, data bits, and stop bits if the user manually changes them during the session. Similarly some of the older public data networks can't talk to a terminal that is set at N/8/1. As all error-free protocols typically require the settings for these to be N/8/1 (i.e. no parity, eight data bits, and one stop bit), parameter 241 allows the SYSOP to have RBBS-PC accommodate these more primitive environments by automatically switching back to the original parameters after the file transfer is complete. Parameter 242 allows a SYSOP to decline calls from new callers based on the baud rate specified. RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 103 of 232 Some SYSOPs believe that 300 BAUD users have a "pre-puberty" mentality and cause more problems (i.e. infantile messages) for the SYSOP than their contributions justify. Another reason for denying access to 300 BAUD users is when RBBS-PC is running in a multi-tasking DOS environment that does not handle 300 BAUD very efficiently (i.e. like MultiLink). While RBBS-PC is intended to be as open a system as possible, each SYSOP has the option of electing to accept calls of only a certain baud rate or higher for new callers. Whatever reasons a SYSOP has for denying access to 300 BAUD users, this option enables the SYSOP to select to do so using CONFIG rather than having to modify the RBBS-PC source code. Parameter 243 allows RBBS-PC to be configured to allow registered users to logon at any baud rate baud even if new users can't. Parameter 244 allows modems that require it, to have "flow control" between the modem and the PC running RBBS-PC using the "clear-to-send" signal, RTS. Some modems with built-in error checking protocols require this to be set on or, should an error-free link become disconnected, the modem will never respond to the PC after RBBS-PC recycles. Parameter 245 allows another method of "flow control" between the modem and the PC running RBBS-PC -- XON/XOFF. Since RBBS-PC attempts to write to the caller as fast as possible, XON/XOFF flow control is normally turned off -- unless parameter 245 has enabled it. When RBBS-PC is attached to a public data network, it can be sometimes necessary to use this method of "flow control" rather than "clear-to-send". Setting this parameter to "yes" means that RBBS-PC will universally support XON/XOFF. However the XON/XOFF check is only made after the buffer is emptied as specified in parameter 54. It is recommended, when XON/XOFF flow control is going to be used, that parameter 54 be set to 32 bytes so RBBS-PC can be as responsive as possible. Parameter 246 specifies the maximum time to wait for carrier after RBBS-PC answers the phone. Some of the "less than perfect" modems disconnect immediately and RBBS-PC would stay "off the hook" long enough to receive the automated voice message requesting the modem to "hang up and please dial again." 11.14 Parameters for RBBS-PC NET-MAIL ------------------------------------- Parameter 261 allows the SYSOP to specify the time of day in HHMM format after which RBBS-PC is to exit after creating a dummy file called RBBSxTM.DEF where "x" is the node ID of the node that EXITed to DOS. By adding two "IF" statements to the simple .BAT file described in Section 14, the RBBS-PC-created file RBBSxTM.BAT will be invoked if RBBS-PC is invoked with the following .BAT file (assuming "x" = node id = 1): RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 104 of 232 IF EXIST C:RBBS1F1.DEF DEL C:RBBS1F1.DEF ' Delete SYSOP F1 semaphore IF EXIST C:RBBS1TM.DEF DEL C:RBBS1TM.DEF ' Delete Time to go to DOS semaphore IF EXIST C:RCTTY1.BAT DEL C:RCTTY1.BAT ' Delete batch file for DOOR exit RBBS-PC.EXE 1 RBBS1PC.DEF ' Invoke RBBS-PC for node 1 IF EXIST C:RBBS1F1.DEF GOTO EXIT ' Check for SYSOP F1 key pressed IF EXIST C:RBBS1TM.DEF C:RBBS1TM.BAT ' Check for Time to go to DOS IF EXIST C:RCTTY1.BAT C:RCTTY.BAT ' Check for exit to a DOOR C:RBBS.BAT ' Re-invoke RBBS-PC again :EXIT The above assumes that RBBS-PC node is "1", the name of the file that invoked RBBS-PC is RBBS.BAT, and everything is in the same DOS subdirectory on the "C" drive. Obviously, this example can be made more generic. The file that RBBS-PC exits to is named RBBS1TM.BAT (but it could be named anything that the SYSOP desired). It is the responsibility of the SYSOP to name and create the RBBS1TM.BAT file. A simple such file that invoked Kim Wells' utility MU-PURGE and then re-invoked RBBS-PC would contain the following two statements: MU-PURGE PURGE.CTL RBBS.BAT As always, .BAT files are limited only by the creativity of their authors. Parameter 262 allows RBBS-PC to handle "store-and-forward" mail of messages and files. Currently the only such "net mail" that is compatible with the FIDO store-and-forward mail specification is supported such as FIDO, SeaDog (see Appendix V) and BINKLEY TERM. By enabling this option, the SYSOP assumes the responsibility of configuring the "net mail" application to 1. answer the phone and determine if the caller is sending "net mail". 2. if the caller is not sending "net mail", the net mail application must invoke RBBS-PC with the following command line: RBBS-PC.EXE nodeid filename /time /baud where: "nodeid" is the node ID in the range 1-9, 0, or A-Z. "filename" is the fully qualified file name to use as the RBBS-PC ".DEF" file. "/time" is the time of day for RBBS-PC to return to the "net mail" application that called RBBS-PC. "/baud" if the baud rate that the caller dialed in at. Parameter 263 is intended to be used when RBBS-PC is connected to a public data network (PDN) as a "node" -- not all systems that people log into on a PDN need be "main frame" computers! When RBBS-PC is a node on a public data network, typically the network will do the echoing -- between the caller and the port he/she accesses on the PDN and between RBBS-PC and the port RBBS-PC accesses on the PDN. This causes file transfers to be a problem because the PDN will continue to echo. Therefore it is necessary to be able to go into an "image" mode where data is passed through the PDN intact with no echoing. The contents of this string is obviously dependent on the predilections of the PDN that RBBS-PC is attached to. The string is RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 105 of 232 sent just before a file exchange occurs. Any character can be included in the string using it's decimal ASCII equivalent simply by putting a number inside square brackets. Characters not in square brackets will be transmitted as they were entered. The string "a[32]" will be interpreted as a lower case letter "a" followed by a blank. Parameter 264 is intended for situations where RBBS-PC is a node on a PDN. It is the string that sent following a file exchange that causes the PDN to resume echoing. As with parameter 263, the contents of this string is entirely dependent on the predilections of the PDN that RBBS-PC is attached to. Parameter 265 allows the SYSOP to specify the default mode of who echoes characters back to the user. Normally RBBS-PC echoes each character that the caller types back to them. An individual caller can set their preference for who is doing the echoing in the Utilities subsystem within RBBS-PC. Callers using telecommunications devices for the deaf (TDD's) or using PDN's that do local echoing can dramatically improve their through put by not having RBBS-PC echo characters back to them. Parameter 266 allows the SYSOP to force RBBS-PC to acknowledge each line uploaded via the ASCII file transfer with a character string. Typically, an ASCII upload is characterized by two fundamental features -- it contains no unprintable characters and it does not require any "error checking". Under some circumstances a callers communications protocol may require a response from RBBS-PC (i.e. a line feed) before the next line will be transmitted. 11.15 New Users Parameters -------------------------- Parameter 281 allows the SYSOP to elect to not ask new users for their default parameters. RBBS-PC typically asks new users whether their terminal supports upper case, whether they want line feeds, what they want for a graphics preference, what they want for a default protocol, and whether they want "turbo-key". Sometimes these questions confuse new users, who lack the knowledge to answer them. To bypass the questions and force new users to get the defaults (upper and lower case, line feeds, no graphics, no protocol, no nulls), specify "NO" this parameter. Parameter 282, parameter 281, parameter 282, parameter 283, parameter 284, parameter 285, parameter 286, parameter 287, parameter 288, and parameter 289 are not implemented in RBBS-PC. Parameter 290 controls whether new users are logged to the USERS file. RBBS-PC normally logs new users in the users file and recognizes them as having previously logged on should they call back. If the SYSOP wants new users not to be logged to the users file specify "NO" to parameter 290. Parameter 291 allows the SYSOP to permit RBBS-PC to continue operating should the users file run out of room for new users. Until the SYSOP rebuilds the users file or expands it, there are then two options: 1. do not let the new user on, or 2. let the new user on but do not try to add him to the user file. RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 106 of 232 Saying "YES" to parameter 291 enable new users to be allowed on on when there is no room rather than being told there is no room and then disconnected. 11.16 Use of the Library Sub-System ----------------------------------- Parameter 301 allows the SYSOP to designate/activate the Library-Subsystem. The default for this parameter is "<none>". This deactivates the function in its entirety. To activate the Library-Subsystem select this parameter and specify the drive that contains your Library Disks. Note: This drive MUST be a separate drive and not the same drive as any other drive in use by RBBS-PC. If RBBS-PC is going to be run on a single hard disk and the Library-Subsystem activated, PC-DOS 3.1 or greater and the SUBST command must be used to allocate the library disks to a pseudo drive different from the other drive in use by RBBS-PC. Parameter 302 is used to select the drive\path where RBBS-PC should look for the upper level file directory (CDR.CDR is the default name). This should be the same drive selected in parameter 220. Parameter 303 allows the extension to be used to identify the Library upper level directory to be specified. (CDR is the default). Parameter 304 is used to identify the drive\directory the Library subsystem should use for creating archive files for transmission. Since the input to the archive function would be one 360k floppy disk worth of data the space requirements will be less than 360k. A RAM disk for this use should be considered. In every case the fastest disk drive available should be specified in this parameter. Parameter 305 is used to specify the highest disk number available in the Library. This value is used in editing the user request for access to the Library. Parameter 306 is used to specify the maximum number of upper level directories that will be found on the Library disk. The PC-SIG CD-ROM is organized with 10 upper level directories, 1-100, 101-200, 201-300 etc. and each of these contain 100 directories, DISK001, DISK002 etc. Parameter 307 is the maximum number of subdirectories that each upper level directory can contain. (100 in the above example) Parameter 308 is used to specify the prefix of the lower level directories. (DISK in the above examples). Since the user enters only the disk number that is desired, RBBS-PC creates the subdirectory name based on this parameter and the number entered. Parameter 309 is used to identify the drive\path\name of the Library Sub- system menu. MENU6 is the default. Parameter 310 is a list of the symbols that are available from the Library Sub-System menu. RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 107 of 232 Parameter 311 contains the security values related to the symbols listed in parameter 310. Parameter 312 is used to identify the drive\path where the archive utility program can be found. (Be sure that is where it is!) Parameter 313 is used to identify the archive utility that you wish to use to do the archiving process on Library disks. When answering the questions to this parameter you will also be asked what the CREATE parameter is. For PKARC and ARC the correct response is "A". If using ARCA there is no CREATE parameter since CREATE is the only function that it can do. Therefore just press enter without entering a CREATE command. 11.17 RBBS-PC's Parameters for Color ------------------------------------ A detailed explanation of the use of colors within RBBS-PC can be found in section 8.10. Parameter 321 is the string that turns ON highlighting or emphasizing of characters in text strings displayed to the caller. The RBBS-PC default is a bright foreground on a red background. Parameter 322 is the string that turns OFF highlighting or emphasizing of characters in text strings displayed to the caller. The RBBS-PC default is amber foreground (normal yellow) and black background. Parameter 323, parameter 324, parameter 325, parameter 326 and parameter 327 are used in conjunction with one another. Parameter 327 is used to offset commands a caller actually needs to type in to select an option. 12. THE HAYES MODEM SWITCH SETTING AND CONSIDERATIONS ------------------------------------------------------ 12.1 Hayes Smartmodem 1200 Switch Setting Considerations -------------------------------------------------------- RBBS-PC is tested with a HAYES Smartmodem 1200 (i.e. external). The switch settings on the modem must be as follows: switch -- 12345678 setting - UUDDDUUD Recognizing that there are many "Hayes-compatible" (and not so compatible) modems in use, this section is intended to assist those adventurous souls who use such modems and need some guidance on what the otherwise mystical Hayes switch settings mean. The following table may be of some help: Setting Function to RBBS-PC Hayes | Factory | RBBS-PC | Switch |---------|---------| (NOTE "Up" means enabled or "on") 1 Down Up Allows RBBS-PC to control the modem using the RS-232 DTR lead (pin 20). 2 Up Up Not meaningful to RBBS-PC (could be down) and is used to indicate if result codes are to be English words or single digits. RBBS-PC sets this with the Hayes "V" command. 3 Down Down Not meaningful to RBBS-PC (could be down) and is used to indicate if result codes are to be RBBS-PC Version CPC17-1A October 2, 1988 Copyright 1988 by D. Thomas Mack Page 108 of 232 sent to RBBS-PC. RBBS-PC sets this with the Hayes "Q" command. 4 Up Down The modem does not echo characters unless half-duplex is selected and the modem is on- line. 5 Down Down Modem is NOT to answer incoming calls. RBBS- PC monitors the ring indicator (pin 22) to determine if the phone is ringing. If it is, RBBS-PC will issue the necessary commands to the modem. 6 Down Up RBBS-PC checks for the carrier signal using the RS-232 Carrier Detect lead (pin 8). If carrier is lost, RBBS-PC hangs up the phone and re-cycles to await the next call. 7 Up Up Not really required by RBBS-PC. However in the "down" position, the telephone extension light will illuminate on a multi-line installation when the modem answers a call. 8 Down Down Enables the Smartmodem 1200 to recognize the Hayes commands issued by RBBS-PC. The most common problem, "RBBS-PC continually recycles," occurs when switch six is left in the factory position. These switch settings do not have to be changed for most other communications software packages. (You can leave the switches set as shown above if you use PC-TALK for your smart terminal communications. However, you will be advised to give the modem an "ATZ" command before using PC-TALK in order to reset the registers correctly.) RBBS-PC should be used only with versions 123 and above of the Hayes Smartmodem 1200 and with version 247 and above of the Hayes Smartmodem 2400. Earlier versions do not answer the telephone properly. The ATI command will cause the Smartmodem to tell you its version. Hayes is now shipping an external modem called the Hayes 1200FE that has 10 switch settings. To run RBBS-PC switches 9 and 10 of the 1200FE must be left up (the factory setting). Hayes is also now shipping an internal modem called the Hayes 1200BFE that has 6 switch settings. To run RBBS-PC switches 4, 5, and 6 must be left up (the factory setting). If you can't figure out what the switching settings on these new modems should be based on the switch settings given for the "original" Hayes 1200, CALL HAYES TECHNICAL SUPPORT! Since I don't have the newer modems, I won't be of much help if you call me. 12.2 Hayes Command's Considerations ---------------------------------- The Hayes commands used to control the modem are all external to RBBS-PC beginning with version CPC13-1A. These command strings are in the RBBS- PC.DEF file which may be modified using CONFIG parameter 225. The RBBS-PC.DEF file contains five Hayes command strings -- one on the second line of the .DEF file and four on the last line of the .DEF file. Using RBBS-PC's CONFIG utility's defaults, the command strings are as follows.